Serve /error paths from back-end, and remove those routes from front-end

[louh]

As a single-page app, Streetmix has been designed in such a way that the front-end holds a lot of responsibility for things that have traditionally been handled by the back-end: routing, for example. In particular, we have a particular series of routes which are intended to halt the application because an error has occurred, for instance: https://streetmix.net/error/authentication-api-problem

This issue is meant to focus on a class of errors that are reached by routing to a URL that uses the /error/ path. It is not meant to address generic application-wide errors, such as a 404 error (although it is, of course, related. See prior art section, below).

Current code references

• Where the page URL is parsed for the /error/ path
• Where the page URL fragment after /error is handled
• The React component that displays the error message

The problem

The current arrangement requires loading the entire application JS bundle in order to display the error message. Load times are increased. This can be a poor user experience, and also demands higher resources from the server if any additional requests are made before the application is halted.

The proposal

Because these errors are served at a route, the back-end can serve static pages for these errors, rather than the entire application.

Known gotchas (thorny problems to solve)

• Not all errors are good candidates for back-end static-page implementation, especially if they also contain UI interactions that depend on the front end code. Errors of this type may need to be reworked, or they may need to remain in the front-end code. (See, for example, errors that call the sign-in dialog, or include a user avatar.)
• Static page errors need to be localized. When error messages occur on the front-end, they could be localized using the react-intl library and the translation strings, which are already loaded as part of the application bundle. When served as static pages, localization needs to be done in a different way. Some proposals include:
  • Do nothing. Let the user agent (browsers) determine what to do with English content.
  • Serve static, localized versions of the error page by detecting the user agent language and routing to a URL with a locale fragment, e.g. https://streetmix.net/error/de/authentication-api-problem
  • Serve dynamic pages with JavaScript that detects the user agent language or the user preference stored in localStorage, and updating the text inline.

Prior art

• Back end should be serving a 404 (although it's possible this is not currently working as intended). This issue is not meant to fix the prior issue, only to note that we have partially addressed a similar problem in the past and this can be used as a reference.

Prior issues

These issues may be addressed in the scope of this issue.

• Display useful headers (e.g. title elements) for error pages. (Better page title for 404 (and other error pages). #229)
• Show a logo somewhere on the error page. (Add logo to loading and error pages. #233)