Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Remove Event system #531
Expanding on #469 (comment):
We've had some offline discussions about this, but this deserves a more public issue both to allow any further input folks might have, and to tie to forthcoming PRs on the topic.
Two parallel callback trigger systems:
This was referenced
Jan 9, 2019
We prefer using Event for things like button clicks as it needs less explanation for people who aren't so familiar with Dash. The n_clicks and timestamp methods also feel like tricks or workarounds much like hidden div did until you created store.
Until this point I had assumed that Event was as a new thing that was being added to replace the other tricks.
I may be alone in this though in which case, we'll stop using Events
@mungojam from our side,
That said it may be worthwhile discussing as part of this issue whether or not we really want the callback to fire on initialization - if we skipped this, switching from an event to the corresponding property really would be as easy as changing the argument. @plotly/dash any thoughts about this? Is there a reason to keep the zero-state callback for event-derived properties?
Note that timestamps aren't necessarily part of this discussion at all - the possibilities they open were not available at all with events, so we would have needed to add them, or something else to accomplish those goals, regardless of our approach with events. That said, if we do use timestamps as a property it seems even more incongruous to have the trigger itself be a non-property event.
From my perspective the benefit of removing events is primarily simplicity:
I agree with everything that @alexcjohnson mentions above.
In addition, removing events is easier for component authors as there is less ambiguity about "what should be an event". For example, clicking on points in a graph: with stateful properties, it's
With respect to documentation and "how new is event?",
For callback firing on initialization, I think that gets to the default properties discussion here: #468. For event-driven properties, we don't always want to skip the initial callback. Consider a
@app.callback(...) @app.skip_initial_update def update_graph(...) # ...
for now, the official way is to raise
@app.callback(...) def update_content(n_clicks) if n_clicks is None: raise dash.exceptions.PreventDefault
which I agree is tedious, however it is consistent with how the rest of the system works.
That all makes sense. I guess I prefer the dialect I made up with the addition of Source() so you wouldn't need the timestamp to identify the source component. But I totally get that you are trying to minimise the number of concepts.
A bit OT but I'm intrigued to see how client side callbacks turns out because the proposal seems to be closer to the style I'd like for python callbacks too