Custom 500 page

[egoist]

No description provided.

[egoist]

You can add a route {path: '*', component: NotFound} to handle 404 though. And custom 500 page is not that important.

[jazoom]

Perhaps this could just be a string field in Ream's config? For example:

const app = ream({
  error500: fs.readFileSync('./error-500.html')
});

[egoist]

I think it's a good idea to export Error component in entry file to handle errors.

[egoist]

https://ream.js.org/guide/custom-error-page.html

Now it handles 404 error using a Vue component.

[IlyaSemenov]

Are contributions still welcome? I need a custom 500 page but my latest PRs seem to be stuck.

[IlyaSemenov]

For now I'm using this app enhancer plugin to show error page on demand (plus a catch block inside getInitialData, which is cumbersome, but currently there is no way to intercept getInitialData calls from the plugin):

export default ({
  ssrContext,
  router,
  event,
  getInitialDataContext
}) => {
  getInitialDataContext(context => {
    context.error = function (error) { // eslint-disable-line handle-callback-err
      if (error instanceof Error) {
        error = {
          code: 500,
          stack: __DEV__ && error.stack // eslint-disable-line no-undef
        }
      }
      router.app.setError(error)
    }
  })

  event.$on('before-server-render', () => {
    const error = router.app.error
    if (error) {
      ssrContext.globalState.error = ssrContext.reamError = error
      if (error.code >= 400 && error.code < 600) {
        ssrContext.res.statusCode = error.code
      }
    }
  })

  event.$on('before-client-render', () => {
    const error = window.__REAM__.error
    if (error) {
      router.app.setError(error)
    }
  })
}

[IlyaSemenov]

window.__REAM__ is now referenced in at least 4 different places (client-entry, renderTemplate, vuex plugin, and the error plugin above).

This is because on the server side, the global data is handled uniformly via ssrContext.globalState, but there is no client counterpart. I believe it's a bad practice; it should be handled on the client side similarly to the server side (extracted from window only once and then passed through the stack, e.g. in createApp context).

I believe we can just unify the two into single context.globalState (not ssrContext.globalState), serialized into <script>window.__REAM__ = ...</script> on the server and then restored from window.__REAM__ on the client.

Then I think __REAM__ wording should be overridable via ream.config.js.