Comments (7)
This is essentially the statement that django-plotly-dash
does not support duplicate callbacks.
Are you in a position to make your callback structure less ill-defined and consolidate the calculations so that only one callback is used for an output value? If the multiple callbacks are non-trivial to combine you could insert a dummy hidden output for each callback (add in also a timestamp or similar if you need to work out which one to use) and then add a third callback to determine which is to be used.
Given that multiple callbacks implicitly say 'use whatever arrived the most recently, dont care what that is' then at worst this introduces the overhead of a third callback (which one could make run locally in the browser if an issue) but also permits the question of which value to be used to be directly addressed.
from django-plotly-dash.
I would also like to use allow_duplicate
in a django-plotly-dash
app!
For what it's worth, the race condition described by @delsim does not necessarily arise if prevent_initial_call=True
is used in all (or even all but one) of the callbacks involved and some pathological patterns are avoided. The Plotly team created this argument/feature in Dash 2.9 because it can absolutely work.
@delsim any chance this argument will be supported in django-plotly-dash
? Any comment on why it doesn't work already (to the extent to which DPD is a wrapper to Dash, I don't see exactly where it should fail).
Thank you so much for any response on this!
from django-plotly-dash.
I would also like to use
allow_duplicate
in adjango-plotly-dash
app!For what it's worth, the race condition described by @delsim does not necessarily arise if
prevent_initial_call=True
is used in all (or even all but one) of the callbacks involved and some pathological patterns are avoided. The Plotly team created this argument/feature in Dash 2.9 because it can absolutely work.@delsim any chance this argument will be supported in
django-plotly-dash
? Any comment on why it doesn't work already (to the extent to which DPD is a wrapper to Dash, I don't see exactly where it should fail).Thank you so much for any response on this!
Ah @delsim sorry for my confusion, I found that allow_duplicate
does already work. prevent_initial_call
has to be used on all callbacks that use this type of Output
, as documented by Plotly.
@zyassine perhaps that answers your question?
from django-plotly-dash.
Whoops - @delsim I notice allow_duplicate
works only in the sense that the Dash app starts, but the Output
functionality doesn't actually send anything to the component properties with the allow_duplicate
argument (even if they in fact only have one Output
)!
@zyassine perhaps this is what you referred to originally.
from django-plotly-dash.
@delsim I am noticing the same thing that @zyassine and @zachsiegel-capsida are seeing and would love the allow_duplicate
functionality to work for my django-plotly-dash
app. As @zachsiegel-capsida said, you can add the allow_duplicate
argument to a callback and the application starts up as expected but the expected update is never seen when the callback runs. (e.g. if the callback fires on a button click and changes the children
of another element, the button click doesn't raise any error, but the output element's children
component is not changed at all)
Any more updates on this functionality? Personally would be using it because I have a bunch of input elements that correspond to local session storage items and would want a change to any of the inputs to update the session storage that it corresponds to. Therefore, I want multiple callbacks pointing to update the same session storage object.
from django-plotly-dash.
@zachsiegel-capsida I'm struggling to see how prevent_initial_callbacks
can stop a race condition. If I have two callbacks that both update some target value, and some interaction in the UI causes first one and then shortly after the second to be called, there is no way of controlling which one will return first.
Whilst this issue might not manifest on a single-threaded synchronous server such as the test ones in Django, Flask etc., as these will only process the callbacks in order, it will nevertheless become quite apparent as soon as one moves to a production environment and uses multiple threads or processes or an async server; there is no guarantee of the order in which the callbacks will return their value to the server. There is a note to this effect in the dash documentation.
@ryan-bloom what stops you having each callback update a separate value and then combine all of these values into the session object with an additional callback? Or, if the purpose of the session object is to maintain some server-side composite record, make updating it a side-effect of a callback rather than its return value.
from django-plotly-dash.
@zachsiegel-capsida I'm struggling to see how
prevent_initial_callbacks
can stop a race condition. If I have two callbacks that both update some target value, and some interaction in the UI causes first one and then shortly after the second to be called, there is no way of controlling which one will return first.Whilst this issue might not manifest on a single-threaded synchronous server such as the test ones in Django, Flask etc., as these will only process the callbacks in order, it will nevertheless become quite apparent as soon as one moves to a production environment and uses multiple threads or processes or an async server; there is no guarantee of the order in which the callbacks will return their value to the server. There is a note to this effect in the dash documentation.
@delsim I totally see your point! Thanks so much for this response. I do stand by my comment below, though:
For what it's worth, the race condition described by @delsim does not necessarily arise if prevent_initial_call=True is used in all (or even all but one) of the callbacks involved and some pathological patterns are avoided. The Plotly team created this argument/feature in Dash 2.9 because it can absolutely work.
You're taking issue with my claim that only "pathological patterns" cause race conditions and I see your point, but it is possible to avoid them to an acceptable level in practice and that's why Dash supports allow_duplicate
! One way is disabling interactive UI elements and showing spinners via clientside callbacks to discourage or prevent multiple triggers. Furthermore, the previously-required Dash pattern of setting up dummy hidden output elements that all write to the real output element via a single callback ALSO suffers from race conditions for the same reason.
Enforcing this pattern in django-plotly-dash when Dash no longer enforces it is probably not what most people expect from this (excellent!) package. I think most people want/expect a wrapper that lets them use Dash from Django, and the more the django-plotly-dash interface deviates from Dash the more difficult that will be (and the more documentation dpd requires to clarify those differences).
As always thank you for maintaining this package and for responding thoughtfully to GitHub issues!
from django-plotly-dash.
Related Issues (20)
- Using dash_leaflet causes js library to fail HOT 9
- Using dash-tradingview dash_tvlwc breaks the app in Django HOT 2
- Improve configuration documentation
- How to pass multiple pandas Time Series (created in Django view) to Dash callback? HOT 2
- allow_duplicate output fails silently
- Bootstrap 5 incompatibility
- How to make Playable Gifs for Django Dash? HOT 1
- AttributeError: 'function' object has no attribute 'expanded' HOT 4
- Assets not fetched correctly while using plotly_direct template tags HOT 7
- Enable get_asset_url to be used for file names passed to the DjangoDash constructor
- Support for Django 5.0 HOT 5
- plotly_direct tag overwrites template style set in base.html HOT 3
- Enable use on Django 5.0
- Increase dash version to 2.10 or greater HOT 3
- Dash Vega Components HOT 1
- Update documentation to refer to bootstrap 5
- plotly_direct HOT 4
- returning data from plotly to django HOT 1
- How to query database and pass it to the `plotly_app` HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from django-plotly-dash.