-
-
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
determine which input is triggering in callback #59
Comments
Have I believe you will have to write three different call backs and use the beta feature of EVENT and STATE to provide input to the function to generate output. |
Can you provide a bit more detail on what the EVENT and STATE features are and how to use them? I can't find any information in the documentation about them. |
https://gist.github.com/chriddyp/e546a2a2c05df29c868e4cef57fb2105
On Jul 1, 2017 5:51 PM, "Brian Cherinka" <notifications@github.com> wrote:
Can you provide a bit more detail on what the EVENT and STATE features are
and how to use them? I can't find any information in the documentation
about them.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#59 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AMct3xa2VyA-4x6T2xALNkdBVS3GEy_vks5sJjnTgaJpZM4OK1fi>
.
|
Thanks for the link, but this isn't entirely helpful. There's no description of what events and states are. I get what events are, i.e. similar to events in javascript, but what are states? In this example code, they look exactly like Inputs. What's the difference between an Input and a State and how do I use States? Can I use them to distinguish which Input triggers a callback? |
@havok2063 States are arguments passed to the function of the callback that won't trigger the callback itself. So changing the code you provided:
In the above code only changes on the relayoutData of plotB would trigger the callback, changes to the layout of plotC would not trigger the callback itself. plotC's relayoutData will be passed into In terms of what you're trying to do, it might be bit tough to figure out directly which input triggered the callback, but one thing you could do is to have two hidden
And to reset the values of There might be easier ways to do this but this is one that came to mind. Let me know if my answer was hard to follow or if I could clarify something. |
Great question @havok2063 !
This isn't possible in Dash. One core concept with Dash is that the app is described entirely by its current state and not by the order of events. This concept makes its easier to reason about the app's logic and it forces the user interface to be consistent with exactly what you see on the screen (and not by the steps that were taken to get there). I think that in most cases, the Dash app developer shouldn't need to know the order of events. If they do, it usually means that the component needs to be patched in a way to make it more stateful or the UI needs to be redesigned. I'll leave this issue open to invite examples of good UIs that are impossible to create without supporting "order-of-events".
In this case, our app logic shouldn't depend on the most recent action, it should depend on the current state of the other graphs. For example, if Here is how I recommend doing crossfiltering for now. A few things to note:
|
Hi, I have a somewhat related design issue with the single
Those inputs should then update a graph, showing the desired frame. @app.callback(
Output('graph', 'figure')
[Input('frame-num', 'value'),],
events=[Event('backward-button', 'click'),
Event('forward-button', 'click'),]
) How can I distinguish between the two events (to decrement or increment my frame number)? Thanks for the good work! |
@glyg I'm facing the same issue |
@glyg I thinks this is key from @chriddyp 's comment above:
For your example, the frame to display is simply the
|
Hi @jwhendy, thanks for the suggestion! I thought about it actually but was a bit worried about the behavior at boundaries: if you keep on clicking the back button when you already reached 0, you'd need to click forward as many times without seeing anything happening .... |
@glyg ah, I get it now. I don't know Indeed, my mind keeps thinking of separate callbacks per button (which would update the same output) or needing to do something inelegant like hide "helper variables" inside of a |
This feature is being considered through the |
This is going to be a problem for me, as my app will have buttons with id dynamically generated, and one output area. There may be work-around, but it would mean extra labour. |
* bump archetype version * install eslint globally, fix tabs * install requirements * clean up tests * unittest instead of implicit nosetest, all versions of python * rm 36 for now * just python 2 for now * typo * increase length of timeout * log the layout * remove duplicate visit
* Fix setProps bug * bump version
* Fix setProps bug * bump version
* bump archetype version * install eslint globally, fix tabs * install requirements * clean up tests * unittest instead of implicit nosetest, all versions of python * rm 36 for now * just python 2 for now * typo * increase length of timeout * log the layout * remove duplicate visit
Since only a single Output is allowed in a callback, and all Inputs must feed into it, how can we determine which input is being triggered during a callback? I have three time-series line plots that I want to cross-filter, and update, any time a range is selected in any of the other plots. For example, the range of Plot A should update when either the range of Plot B or Plot C is updated. But the callback collects the ranges from all plots simultaneously. Is there a way to get the id of which input was triggered during a callback?
Here is my code but it only updates with data from plotB, when it is triggered. When I update Plot C the datac variable is indeed updated but the data from plotB is also passed in again, so the callback function has no knowledge of which plot is actually triggering new input.
The text was updated successfully, but these errors were encountered: