[Tidy] Convert built-in actions to pydantic models

[antonymilne]

Description

Built in actions

User API:
Before: actions=[vm.Action(export_data(...))]
After: actions=[export_data(...)]

The old version still works for backwards compatibility but will go in 0.2.0. export_data will stay in 0.2.0 but filter_interaction will not.

What's changed?

• these actions are now pydantic models and hence have a schema, validation, etc.
• _callback_mapping is completely gone. Instead these are done next to the function definition in the export_data etc. class
• no more action.function._function.__name__ != "_filter" comparisons or _parameter.__wrapped__ things; instead we can do isinstance(action, _filter)

Custom actions

User API:
Before: actions=[vm.Action(function=my_custom_action(), inputs=["dropdown_id.value"], outputs=["card.children"])]
After: actions=[vm.Action(function=my_custom_action("dropdown_id.value"), outputs=["card.children"])]

Before: define action with @capture("action") and a function definition
After: same still works but there's also a new possibility to do class my_custom_action(AbstractAction) for advanced users. These are slightly more powerful than the function variety and can be used as if they were built in actions, like actions=[my_custom_action(...)] without needing the vm.Action wrapper.

The old version still works for backwards compatibility but will go in 0.2.0. In 0.2.0 passing static arguments to a custom action is only possible through the class definition approach (though if we really need to in future we could enable it in the function approach too).

What's changed?

• users can use special arguments like controls directly in their actions to use built in Dash states
• inputs are specified directly as function arguments rather than through inputs which is way clearer

In future:

• add more built in states, including trigger to get the state of the trigger that can be easily consumed in the action without having to explicitly give the component an id
• possibly a new Python shorthand to do something like actions=[my_custom_action("dropdown_id.value") >> ["card.children"]] which is equivalent to actions=[vm.Action(function=my_custom_action("dropdown_id.value"), outputs=["card.children"])]
• remove need to specify full <component>.<property> in favour of just doing <component> and using the relevant model's default property. So you'd just do card rather than card.children

Notice

• I acknowledge and agree that, by checking this box and clicking "Submit Pull Request":

  • I submit this contribution under the Apache 2.0 license and represent that I am entitled to do so on behalf of myself, my employer, or relevant third parties, as applicable.
  • I certify that (a) this contribution is my original creation and / or (b) to the extent it is not my original creation, I am authorized to submit this contribution on behalf of the original creator(s) or their licensees.
  • I certify that the use of this contribution as authorized by the Apache 2.0 license does not violate the intellectual property rights of anyone else.
  • I have not referenced individuals, products or companies in any commits, directly or indirectly.
  • I have not added data or restricted code in any commits, directly or indirectly.

[petar-qb]

Other actions requiring the insertion of dash_components could be:

• drill_through_action – if we choose to implement it using dcc.Store instead of relying on Dash routing callback inputs.
• navigate_to_page("page-2") – if we opt to use dcc.Location for navigation.

Also, since dash_components are "magically" hidden, we should clarify in the documentation how this argument is used, where these components live in the HTML DOM, and why they are hidden.

[antonymilne]

My idea here is that we have some components that are available for all actions to use as output with some reserved names, e.g. maybe prefixed with vizro_:

• definitely useful: vizro_download, a dcc.Download component
• definitely useful: vizro_location, a dcc.Location component (same as the Dash pages one but public)
• possibly useful: vizro_store: a dcc.Store

Then you'd be able to write an action with output=["vizro_download"] for example to use this. So individual actions wouldn't need to ever create new components, just use existing built in ones.

However, there are some assumptions here we should discuss since I'm not sure whether they hold...

• all these components are hidden and globally available on all pages
• it is ok for there to only be one of each component. e.g. we would need to change the current implementation of export_data to zip the files into one file and then send that to the single vizro_download object rather than dynamically creating n dcc.Download components like it does now. Would this work ok with dcc.Store?

If we're not 100% sure but think this scheme will probably work then I'd like to try and do it because it would help us remove the whole dash_components thing which is only necessary for a couple of actions.

wdyt?