Callback error awareness

[jarias]

Hi all

Right now, dash renderer injects some handy divs in certain situations that can be useful to update the interface when interacting with the server:

• ._dash-loading: at startup, when react and the remaining of your index is loading. It is maintained as well during the initial lifecycle of the application, that is calling the server for GET _dash-layout and GET _dash-dependencies.
• ._dash-loading-callback: when you call the server for POST _dash-update-component, once the page is loaded and each time any input is modified.
• ._dash-error: Actually called when the first stage I have describe above fails. The content of the dashboard is not rendered and this div is injected.

Styling these three divs with custom CSS (especially with pseudoelements) allow you to add nifty loading and error pages, however we have a major use case that is problematic,

I feel that ._dash-error should be injected also when POST _dash-update-component returns either 400 or 500 errors so we can style it accordingly and add awareness to the user. Right now the only workaround we have is to catch all exceptions in the callback and return any html code to show the error as suggested by @chriddyp here:

Informing user of callback exceptions

i switched to creating all my callbacks programmatically, so i handle all errors in the function that creates the callback this is useful mostly for logging the errors (i found that exceptions in callbacks fail silently otherwise ,due to that suppress exceptions flags in a multi page app) if there is a way of firing an event from within a callback and by that updating another output component (not the one used in the callback definition, that would solve the issue of displaying the error to t…

This solves many use cases, but we still have problems for error responses that do not originate as python exceptions, such as timeouts or proxy authentication rejects…

Also when these errors occur, the ._dash-loading-callback does not disappear, so my custom loading style is kept indefinitely… which also interferes with the previous approach.

I think it would be more consistent to allow the renderer package to show the state of http requests all by itself, it won’t be much difficult to implement right now with the current redux state (I am not yet familiarised enough to create a PR but I can try to help!)

Cheers,

[chriddyp]

Yeah, that’s a interesting idea. Many times error messages should be localized on the component level. We’re improving the loading states UI by introducing per-component loading messages (https://github.com/plotly/dash/issues/267), perhaps we could do something similar with error messages.

Let’s create an issue in dash to work out a couple of different architectures.