fusionjs / fusion-react-async

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Error handling does not work when rendered server side.

saspre opened this issue · comments

Type of issue

Bug

Description

When using split the ErrorComponent does not get used when the page is rendered on the server.

Current behavior

When the page containing the component above is rendered in the browser the ErrorComponent is shown.
When the page is rendered on the server it fails and the entire page returned is just an Error page.

Expected behavior

The same behaviour irregardless of whether it is rendered server side or in the browser.

Steps to reproduce

Use this test code:

export function MyComponent() {
  const LoadingComponent = () => <div>Loading...</div>;
  const ErrorComponent = () => <div>Error loading component</div>;

  const BundleSplit = split({
    load: () => import(`mycomponent`),
    LoadingComponent,
    ErrorComponent,
  });

  return (
      <BundleSplit />
  );
}

The component loaded by the import throws an Error.

mycomponent.js looks like this:

export default function() {
  throw new Error()
}

Your environment

  • fusion-react-async version: 1.2.0

  • Node.js version (node --version): 8.9.3

  • npm version (npm --version): 5.6.0

  • Operating System: macOS

Fixed an issue where a missing import would cause the process to crash. Released in fusion-cli v1.6.0

After some further investigation, I found that the root of reported issue comes down to the React not supporting componentDidCatch in ReactDOMServer (due to concerns related to streaming rendering), and that due to that limitation, we cannot support a flow where a thrown error from render yields the rendering of ErrorComponent.

From a DX perspective, the current failure mode does display the stack trace of the error, so it is sufficient for debugging purposes.

Further, I don't actually believe Fusion should attempt to recover from a runtime error (by rendering the ErrorComponent in the event of a NPE or similar). If this is desired semantics, I'd recommend using try/catch in the render method, or using standard state management flows to handle "error" scenarios without throwing/unwinding the stack.