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

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.

[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.

[delsim]

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