-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feat] Recognise controls outside page.controls
#903
Conversation
View the example dashboards of the current commit live on PyCafe ☕ 🚀Updated on: 2024-12-02 17:30:20 UTC Link: vizro-core/examples/dev/ Link: vizro-core/examples/scratch_dev |
for more information, see https://pre-commit.ci
vizro-core/src/vizro/actions/_callback_mapping/_callback_mapping_utils.py
Show resolved
Hide resolved
vizro-core/src/vizro/actions/_callback_mapping/_callback_mapping_utils.py
Show resolved
Hide resolved
for more information, see https://pre-commit.ci
page.controls
page.controls
page.controls
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Little refactoring, but big change! 🚀 This is amazing and fixes so many limitations that we've encountered this week.
Understood the main change, and checked all our demos, but I'll leave the action unit tests to @petar-qb :)
Co-authored-by: Li Nguyen <90609403+huong-li-nguyen@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a huge improvement! It's so intuitive to use model_manager helper methods now. 🎖️
@@ -32,21 +32,27 @@ def _get_inputs_of_controls(page: Page, control_type: ControlType) -> list[State | |||
"""Gets list of `States` for selected `control_type` of triggered `Page`.""" | |||
return [ | |||
State(component_id=control.selector.id, component_property=control.selector._input_property) | |||
for control in page.controls | |||
if isinstance(control, control_type) | |||
for control in cast(Iterable[ControlType], model_manager._get_models(control_type, page)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would the _get_inputs_of_controls
be even more flexible if we searched for all _filter
/_parameter
Action functions on the page (instead for vm.Filter
/vm.Parameter
components)? In that case if a _filter
action (or its future public counterpart e.g: filter
) is assigned to the pure dcc.Dropdown()
, this component would behave exactly like the vm.Filter
(except the _dynamic
behaviour and potentially some other.).
This is more like a theoretical question and I guess its answer mostly depends on how we see Vizro backend in future and it also depends on many other decisions (e.g. how to make a standalone dcc.Dropdown to be dynamic, and many many more). Currently, I can't say what exactly are all the pros/cons of this approach and is any new use-case covered with this approach or another. So, this comment here is just an idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question! I'm actually thinking about this already in #363 right now and not yet sure or how to handle it, so let me keep this unresolved to come back to.
The test fails because the Also, couple of these After several refactoring attempts I ended with this stupid solution: def test_all_action_loop_components(
self,
fundamental_components,
gateway_components,
action_trigger_components,
action_trigger_actions_id_component,
trigger_to_actions_chain_mapper_component,
):
result = _get_action_loop_components()
# Validate the action_loop_components_div wrapper
assert_component_equal(result, html.Div(id="action_loop_components_div"), keys_to_strip={"children"})
# Validate the children of the result component.
# Since the order of children is not guaranteed due to how elements are retrieved
# from the model_manager, we perform order-agnostic comparisons.
#
# * fundamental_components, gateway_components, and action_trigger_components:
# These are dcc.Store objects with simple "data" attributes, so we compare their string
# representations directly.
# * action_trigger_actions_id_component and trigger_to_actions_chain_mapper_component:
# These components have more complex attributes, so we compare their `id` and `data`
# fields explicitly. "data" is compared as a set to ignore order.
# Test: fundamental_components + gateway_components + action_trigger_components
expected_children = fundamental_components + gateway_components + action_trigger_components
result_children = result.children[:len(expected_children)]
assert {str(elem) for elem in expected_children} == {str(elem) for elem in result_children}
# Test: action_trigger_actions_id_component
index_action_trigger = len(expected_children)
action_trigger_result = result.children[index_action_trigger]
assert action_trigger_actions_id_component.id == action_trigger_result.id
assert set(action_trigger_actions_id_component.data) == set(action_trigger_result.data)
# Test: trigger_to_actions_chain_mapper_component
index_trigger_mapper = index_action_trigger + 1
trigger_mapper_result = result.children[index_trigger_mapper]
assert trigger_to_actions_chain_mapper_component.id == trigger_mapper_result.id
assert set(trigger_to_actions_chain_mapper_component.data) == set(trigger_mapper_result.data) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀 This will unlock quite a bit quite soon (ie today) 🚀
vizro-core/src/vizro/actions/_callback_mapping/_callback_mapping_utils.py
Show resolved
Hide resolved
…el_manager # Conflicts: # vizro-ai/hatch.toml # vizro-core/examples/scratch_dev/app.py # vizro-core/src/vizro/models/_controls/filter.py # vizro-core/src/vizro/models/_page.py
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
Description
Following a conversation with @huong-li-nguyen and @maxschulz-COL, this should make the functionality of control groups as in #82 work again - see scratch_dev example.
While I was at it I did some tidying and refactoring to the
model_manager
:model.id
directly from the model itself and it means we don't need lots of themodel_manager[model_id]
stuff we did beforemodel_manager
changes are an improvement but definitely need more work - hopefully @maxschulz-COL will work on this in the nearish future after we're on pydantic v2@petar-qb please could you check the failing unit test and see if it's a problem or not? I think there was a bug before in the
model_manager
so don't know if I've fixed that bug or broken something else or if it doesn't matter. Here's the full mesage: https://gist.github.com/antonymilne/7f3a3015772f0c992dd8b1194e6f9489.Notice
I acknowledge and agree that, by checking this box and clicking "Submit Pull Request":