-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Remove Event system #531
Comments
Corresponding issues in the other core repos: |
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 |
this refactoring: plotly/dash#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:
Input
andEvent
Most interactions in dash are handled by properties, referenced by either
Input
orState
as callback parameters, or byOutput
as the result of a callback. But there's also anEvent
system, which can trigger a callback without a value, just based on some event occurring. This system was originally made to handle user interactions with no inherent visible consequences (so they don't have an obvious mapping to stateful properties), like button clicks. But for some time now we've had another way to handle this kind of scenario in a stateful way, which has all the same capabilities and more without needing a parallel system, and a lot of our newer components have no events defined at all. Dash 1.0 is the right time to removeEvent
entirely and only accept the property-based alternative.Transition from
Event
toInput
The key is to create a property that the component modifies every time the event occurs, so that the appropriate callback will fire on every event. We've generally done this by incrementing a counter. The most widely used right now in our codebase is the click event, where instead of emitting a
'click'
event we create a'n_clicks'
property. One complication of this is that in the property version, the callback will be fired on initial render withn_clicks=0
. To get around this, you can usePreventUpdate
:An issue that we never had a simple solution for with
Event
was multiple events triggering the same callback, for example two buttons that should cause the same output component to behave differently. We have another set of properties you can use to handle this, based on timestamps. By convention these properties get the same name as the counter, suffixed with_timestamp
-n_clicks_timestamp
for example, and this would contain the timestamp (milliseconds since 1970) when the latest click occurred:I'll make corresponding issues in the other core repos to track any specific aspects of this relevant there and to link to PRs.
The text was updated successfully, but these errors were encountered: