@Emil posted recently interesting post about Server Side Caching using component from dash-extensions. In the same package, there are two other interesting classes:
CallbackGrouper. Here are some random thoughts which came into my mind. Perhaps we could utilize these components to improve the
@app.callback() a bit?
Triggercomponent is nice. This could also be added to
dash.dependencies, so the callback syntax could be (option A)
@app.callback( [*output], [*inputs, *triggers], [*states] )
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
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 same
Output. 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 same
Outputmultiple times, and it could function like
CallbackGrouperunder 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 to
Dash()), and then if user writes
@app.callback( None, [*inputs], ) def func(): do_something()
Noneoutput would be directed to this
null-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.