Enhance front end exception handling

[masvelio]

Description

Currently, if something is broken in the code, user gets white error screen with vague information. User is in a dead end - only reload can help here.

We should enhance error handling by introducing few improvements.

Engineering Requirements

• use additional ErrorBoundary component that wraps only content of the page, so the sidebar and navbar is still active/clickable when the error happens in the body
• modify error page so it will look like this:
  • warning icon (same as now)
  • header: "Ups, something went wrong"
  • text: "Try reloading the page or contact our team if the problem remains."
  • button: "Reload"
  • text: "Details: {error message}"
• Ideally, when this kind of error happens, we should use rollbar for logging the issue (it should be handled inside ErrorBoundary component) => this way we will be able to track those issues with the rollbar dashboard instead of waiting for users to report the bug to us
• we should be able to quickly find where exactly in the code this issue happened. Currently in production build the code is obfuscated so it is hard to read the trace. We need to figure out if rollbar dashboard would help us here or maybe we would need to apply sourceMaps (depending on the lift, might be separate issue).

[masvelio]

@jnaviask

1. what do you think about idea of using rollbar? Usually for this we would use sentry but rollbar is alternative and since we use it already, maybe we can have it on front end as well.
2. any insights on the source maps? Did we have any attempt in the past? Any roadblocks from your point of view?

[jnaviask]

@masvelio

1. Seems like Rollbar is fairly well supported for the front-end -- I would 100% be happy to see it used as an exception handler: https://docs.rollbar.com/docs/react + https://docs.rollbar.com/docs/react-ts
2. We should have source maps set up per @kurtisassad -- he can provide more context on how/where we use them.

[kurtisassad]

Maybe I am misunderstanding here, but source maps seem to work for me. When I reproduce this error I get:

There are 2 places of distinction here. One is for dev builds, and one is for prod. On prod builds we don't send the source maps over because it adds extra information to the bundle, which increases size and build time. As a result it would take users longer to load the site. I think it would not be wise to send source maps for production builds because it defeats the point of minifying the code. If we plan to send source maps, it is better to just not minify the code in the first place.

On the dev build, we build and send the source maps. They are built via webpack (see webpack.dev.config.js). There are different types of source maps, but we use the cheapest one that still provides a reliable mapping to the original source code. You can find a list of all the source map options here: https://webpack.js.org/configuration/devtool/

[kurtisassad]

Looking into the rollbar issue more, I think it is possible to upload source maps to rollbar after we deploy a new version of commonwealth, so that when we send the minified stack traces to rollbar, it will convert them into full stack traces. In my opinion this would be the area we would want to look into if we want readable front end stack traces on prod: https://docs.rollbar.com/docs/source-maps

But this might take a bit of work, as we don't really have a CD pipeline (We just use heroku to autopull the branch). So we would probably need to do a bit of work to make a script to auto deploy the source maps to rollbar after we deploy our code.

[burtonator]

There are actually two issues here:

1. When unhandled errors are thrown and they break reach then we should have an ErrorBoundary setup.
2. If we can handle an error, like from a promise, we should bring up a snack error message just telling the user that their request failed.