Dash Dev Tools

[chriddyp]

In https://github.com/orgs/plotly/projects/3, many of our issues involve Dash's front-end: Front-end error handling, front-end live-DAG, front-end hot-reload.

I'd like to open this issue to discuss an architecture for handling these requirements.

Some framing:

JavaScript Error Handling

• We should expose Dash's front-end errors to the users. Currently, they are only available in the browser's dev tools, which is too hidden for our community.

For example, consider Atom's plugins:

Python Error Handling
Could we use the same architecture that we use for JavaScript errors to display python errors? That way, the user never needs to look at the terminal for errors, they only need to focus on their app.

For example, consider create-react-app:

or werkzeug:

Hot Reloading
If we had hot-reloading, could we build a nice little "control bar" that users could use to configure hot reloading? For example, it could:

• Tell the user if hot-reloading is on or off
• Users could turn hot-reloading on and off
• It could provide build times or "last updated" times

Displaying the DAG
If we wanted to display the DAG to the user, could we place this in the Dash Dev Tools container as well?

---

cc @plotly/dash

[rmarren1]

React 16 introduced Error Boundaries

Error boundaries are React components that catch JavaScript errors anywhere in their child component tree, log those errors, and display a fallback UI instead of the component tree that crashed. Error boundaries catch errors during rendering, in lifecycle methods, and in constructors of the whole tree below them.

If we upgrade to react 16 we can

1. Change the AppProvider to a class definition
2. Add the new componentDidCatch to set state.hasError = true and state.error = error when an error is thrown in the app
3. In the render method of AppProvider, either only render the state.error if state.hasError, else render

<Provider store={store}>
        <AppContainer/>
    </Provider>

Or even render the app with a small error message bar like here or even design something nice like the atom plugin error message above.

I'll see if I can get a proof of concept / see if it really is that easy...

[nicolaskruchten]

+1 for error-boundaries! it makes React development a lot easier and makes working with sometimes-buggy apps a lot nicer: just parts of the app become unusable instead of all of them :)

[valentijnnieman]

Error-boundaries sound great. Would be very interesting to see that in a proof of concept! I'm not sure about the control bar idea - but's that's just my general preference. Don't really like development UI to be on my web application! But what about maybe a browser plugin, like React devTools has?

[bpostlethwaite]

Ditto, I like the error boundary idea.
I share @valentijnnieman concern about the control bar concept. It may add more confusion and maintenance than it is worth and it would have to be done really well --- there is lower hanging fruit to tackle first.

[rmarren1]

Error boundaries work pretty well. I wrapped the <AppProvider /> with a simple <ErrorHandler /> which catches any errors thrown in the app and displays it to the user.

What may pose a difficulty is that React refuses to render any component which is throwing an exception, meaning components would need to be perfect and not throw any errors. Previously, Dash components could be buggy (e.g. throw some errors to console) and stay rendered on the app (e.g. in this example, you can keep clicking the button and it would stay while throwing an error each click). With this kind of update we would either need to completely unmount the app and display an error message, or put error handlers lower down in the component tree.

I think the logic behind not rendering any components which are throwing an error in a lifecycle method is solid, explained here

[rmarren1]

Looking into this further, it looks like Error Boundaries are not perfect since they only catch errors in lifecycle methods, constructors, and render methods. Front-end errors will work fine, but server side 500 errors will not be caught since they originate from event handlers.

There are two workarounds I have found to get both error types in the same place, which are a little hacky but might be worth it.

1. We could have both front-end and back-end dispatch a new error action to the redux store, and a top level component could then listen for these and conditionally display errors or the app. In the front-end, we can catch errors in a top level error boundary and then dispatch the action in the componentDidCatch lifecycle method, and for back-end errors we could chain a catch method to this promise and dispatch form there. Someone did this and has a minimal example.
2. It seems like setProps is always in the stack trace of 500 errors,
   

perhaps we could catch errors here with something like

export function setPropsWrapper (newProps) {
  setProps(newProps).catch(e => this.setState(() => { throw e }));
}

which would push them up into the react error boundary.

[T4rk1n]

The werkzreug one is sent by flask when debug=True but since it's an ajax calls it won't show, maybe we could have the renderer show it when it receives a 500 code from a callback and debug=True ?

@rmarren1 setProps is always in the stack of error 500 since it's the one that initiate the callback request. But it could also happen in /_dash-layout and the other path the renderer sends ajax requests to.

[rmarren1]

True @T4rk1n, I forgot about those other endpoints. I think then that catching errors in the following three fetch calls then dispatching an error can work for the back-end:

1. https://github.com/plotly/dash-renderer/blob/25e4c566afb9d79685ba065e0a99ff4a00195d7a/src/actions/api.js#L7-L15
2. https://github.com/plotly/dash-renderer/blob/25e4c566afb9d79685ba065e0a99ff4a00195d7a/src/actions/api.js#L19-L28
3. https://github.com/plotly/dash-renderer/blob/25e4c566afb9d79685ba065e0a99ff4a00195d7a/src/actions/index.js#L472-L735

In fact the string fetch( doesn't appear anywhere else in dash-renderer, so I think that is all the network communication to the server-side?

[T4rk1n]

@rmarren1 The first two are wrappers, find the usage of those.

https://github.com/plotly/dash-renderer/blob/25e4c566afb9d79685ba065e0a99ff4a00195d7a/src/actions/index.js#L537-L541

Could dispatch the error from there, the response content type should be text/html and if debug=True in dash the error will have a formatted stacktrace, otherwise it be the generic error 500 message. Maybe dash should send a json error instead and the renderer show the same error component for both front-end and back-end errors ?

[chriddyp]

(semi-related to the immediate discussion above. Here's another interesting solution for displaying logs in the browser, it could be a separate endpoint and read from a file: https://github.com/mozilla-frontend-infra/react-lazylog)

[rmarren1]

^^ I like that, looks like CircleCI output

I've been looking into handling things on the Flask side now. We need a way to catch errors in debug mode and do something with them that makes it available to the front end.

The LazyLog component looks great for this (haven't tried this part, but it looks like with the 'stream' attribute set to true we can continuously listen to an error file), then we would only need to serve an error file from Flask and then write to that file when an exception occurs.

This is what is usually done, but this custom handler is only fired when debug=False, the exception is reraised before the custom handler is called in debug mode.

@app.errorhandler(500)
def error(e):

The flask signals module seems like it provides just what we need. (http://flask.pocoo.org/docs/0.12/api/#signals)

Specifically the got_request_exception signal.

This signal is sent when an exception happens during request processing. It is sent before the standard exception handling kicks in and even in debug mode, where no exception handling happens. The exception itself is passed to the subscriber as exception.

I tested this module in Dash and it works nicely 😄
adding this bit:

        @got_request_exception.connect_via(self.server)
        def when_dash_gets_exception(sender, exception, **extra):
            with open('500.log', 'w') as f:
                f.write(traceback.format_exc())

to dash.py makes Dash print all 500's to a '500.log' text file.

I think this is way easier than catching all the exceptions in the front end! I'll see if I can get it working end-to-end, E.g., server-side errors read by LazyLog which triggers some high order component in react to render an error message. Then we just need to feed front-end exceptions caught with the React Error Boundaries into the same rendering mechanism and I think it would work

[rmarren1]

I have a work in progress going in these two pull requests

plotly/dash-renderer#64
#307

Still trying to figure some small quirks out, but it is at a point where it does what it should locally.

Here's how it looks: