Support for `@app.long_callback` and improved documentation of asynchronous stack

[zachsiegel-capsida]

Hey there,

I am interested in implementing long-running responses. Currently I have configured an app's timeout to 90+ seconds, and have a lot of very customized spinners. However, these long timeouts are bad practice and I should be subscribing to channels.

I have had trouble getting my stack configured to work with web sockets. I already use Redis as a cache and task queue, and I have tried a separate Daphne process, Celery process, and Diskcache. I have tried to set up asgi.py. Can you please add to your documentation regarding this extension?

Alternatively, can you try to implement the Dash abstraction for long polling responses/sockets, which is their "@app.long_callback" interface? If users could simply defer to the Dash documentation, I think it would grease the wheels for a lot of folks.

Thank you so much for providing this open-source software that does exactly what I want. If there is a clear path to me contributing the changes I want to see, please let me know. Since I can't even get it working, though, it's hard to imagine I can make improvements.

[delsim]

@zachsiegel-capsida if it (ie some processing) is something long running, then solving it in a mainstream django way (eg celery) might be worth considering, although obviously it depends a lot on your use case. On a related note, our experience with websockets in general is that they do require quite a lot of work/add complexity and there does need to be a very good reason to justify using them over and above something simpler such as polling with an Interval component or similar.

Did your attempts to use websockets/channels start from the demo site or elsewhere? For sure the documentation is poor on this point, so anything you can share about what you tried would be useful.

[zachsiegel-capsida]

@delsim I'm kind of just holding off on advanced Dash features until DPD upgrades to using Dash 2.0. I may explore contributing to that effort at some point.

[GibbsConsulting]

As of #402 django-plotly-dash should now work for Dash 2.0 and higher

[zachsiegel-capsida]

@GibbsConsulting this is excellent news for me! Thank you so much for your responsiveness on this topic.

I will attempt to upgrade our project in the upcoming 2-3 weeks. I will open new issues if/when they arrive and document our solutions.

I really appreciate you maintaining this project.

[brunoricardi]

I'd love to have @app.long_callback enabled as well. However, with the new version 2.0.0, I get

    @app.long_callback(
AttributeError: 'DjangoDash' object has no attribute 'long_callback'

[zachsiegel-capsida]

@GibbsConsulting I was able to pip install both django-plotly-dash==2.0.0 and django=4.0.2 (as lines in the same requirements.tx), which previously gave error messages and failed! I can confirm our project still works. I have not attempted to use previously-unsupported Dash features yet with this new Django-Plotly-Dash version.

I still get the following error message:

ERROR: django-plotly-dash 2.0.0 has requirement dash-bootstrap-components<1, but you'll have dash-bootstrap-components 1.0.3 which is incompatible.
ERROR: django-plotly-dash 2.0.0 has requirement Django<4.0.0,>=2.2, but you'll have django 4.0.2 which is incompatible.

Previously, I got a similar error and then pip would fail; now, the installation seems to proceed successfully after this error message. (For the record, if I pip installed django-plotly-dash==1.6.6 with the --no-deps option, which ignores potential incompatibilities, the project mostly worked fine).

Is this the expected behavior?

django-plotly-dash==1.6.6	django-plotly-dash==2.0.0
works with Django>=4.0.0 once installed	✔️	✔️
Gives error message when pip installing with Django>=4.0.0	yes	yes⚠️
Succeeds when pip installing with Django>=4.0.0	❌	✔️

I am referring to the "yes⚠️". I believe there should not be an error message when installing django-plotly-dash==2.0.0 with Django>=4.0.0.

Please let me know whether I am correct and what can be done about this.

[delsim]

@zachsiegel-capsida you (should) get the error message, as at the moment the package requirement is for Django < 4.0 - this is essentially as it hasn't been validated yet. In particular some functionality might have to be refactored due to deprecation within Django.

Are you finding that everything works with Django 4.0?

[delsim]

Note that #403 is the task to move to Django 4.0

[zachsiegel-capsida]

In short

• The entire extended callback syntax did not work in DPD 1.6.6 with Django>=4.0. I could not access callback_context, dash_app, dash_app_id, request, session_state, user, or **kwargs as callback parameters. (I was still able to use dash.callback_context.triggered, for what it's worth.)
• With DPD 2.0 and Django>=4.0, I can definitely access these callback parameters. I haven't tested them extensively, but they are definitely available.

Thank you for this update! @delsim please let me know whether I should comment on #403 about my experience.

[gazsi3]

I'd love to have @app.long_callback enabled as well. However, with the new version 2.0.0, I get

    @app.long_callback(
AttributeError: 'DjangoDash' object has no attribute 'long_callback'

Is there any update on this: using long_callbacks?