Hi all,
@Emil posted recently interesting post about Server Side Caching using component from dash-extensions. In the same package, there are two other interesting classes: Trigger
and CallbackGrouper
. Here are some random thoughts which came into my mind. Perhaps we could utilize these components to improve the @app.callback()
a bit?
- The
Trigger
component is nice. This could also be added todash.dependencies
, so the callback syntax could be (option A)
@app.callback(
[*output],
[*inputs, *triggers],
[*states]
)
where Trigger
type of inputs are just not passed over to the callback function. Or even (option B)
@app.callback(
[*outputs],
[*inputs],
[*states],
[*triggers]
)
And since it could be possible to just check the type of app.callback(*args)
arguments, it could be even (option C)
@app.callback(
*outputs,
*inputs,
*states,
*triggers
)
and the ordering of Output
, Input
, State
and Trigger
components could be any actually, but they (Input and State) would be passed to the callback function in the same order as they were given in @app.callback
. Similarly with outputs.
-
There is this
CallbackGrouper
, which makes it possible to assign multiple callbacks to sameOutput
. I think this would be good the merge to the dash core, if it works in all situations. The@app.callback()
could be made to accept sameOutput
multiple times, and it could function likeCallbackGrouper
under the hood.Gain 1: This would mean that there would be one less rule to remember about callbacks, and make dash more easier for beginners.
Gain 2: Much easier to define callbacks when you have same Output used in multiple callbacks
Gain 3: There is also another neat thing that could be accomplished with this. You could (probably, did not try this but I think it should be possible) allow callbacks without Output. How is that? Either, have always a hidden div in dash application with
id='null-output'
or something like that (or have it enabled with a kwarg given toDash()
), and then if user writes@app.callback( None, [*inputs], ) def func(): do_something()
the
None
output would be directed to thisnull-output
, or a PreventUpdate Exception would be raised.with the new syntax (option C) this could be even
@app.callback( Input(...), Input(...), Trigger(...), State(...), ) def func(): do_something()
(note the missing Output). This would be a really clear syntax for callback definition.
What do you think? (Not sure who to tag here, but @chriddyp, @Marc-Andre, others?)