Swallowing a loadable error in an Error Boundary leads to an infinite loop

🐛 Bug Report (/feature request?)

If you swallow a loadable error in an error boundary and render the same tree again, loadable will try to load that chunk once more, possibly triggering the same error, and so on.

In dev, this can lead to an infinite loop, in prod builds React might unmount instead.

Context: Some lazy-loaded components are “optional”, so in our app we often just want to report that they failed loading in an error boundary, but let the users keep using the page.

To Reproduce

1. Wrap app in an error boundary that still renders this.props.children after chunk errors.
2. Provoke a chunk error, for example by blocking that JS-resource in the browser network tab.

Expected behavior

If a lazy loaded component has already failed loading once, I expect the default to be to not try again. Possibly there should be an API to configure number of retries?

Today you would have to wrap every single Loadable in it’s own error boundary that renders null on chunk errors, which is very verbose and cumbersome.

Link to repl or repo (highly encouraged)

This codesandbox works by default and because of how codesandbox works you can’t block the JS-resource, BUT, you can simulate a chunk error by removing the export default in LazyComponent.

https://codesandbox.io/s/loadable-components-error-handling-xh1nn

Note that in our real app, this same error happens regardless of why the chunk failed to load, so for example timeouts or blocking the resource will have the same result.

[Ephem]

I’m not quite sure I understand? ErrorComponent in your post links to the fallback-prop, but I thought that is only rendered during loading precisely because Loadable is stateless (besides the promise itself)? If it does render during error as well, I can’t see a way of having both a loading state and an error state without using error boundaries?

I can see how I could solve this “optional lazy loaded component” case with wrapping each such loadable in it’s own ErrorBoundary that renders null on error though, so if that’s the recommended solution I’m totally fine with that even if it’s a bit clunky. 😄

I’m currently using something like this as a workaround for this issue and #717 , though it’s a bit unstable since it relies on internals:

import * as React from 'react';
import loadableBase from '@loadable/component';

export default function loadable(
  loadableImportObject,
  { ErrorFallback, ...options } = {}
) {
  let memoizedError = false;
  // Danger: Relying on loadable internals here!
  const originalImportAsync = loadableImportObject.importAsync;

  loadableImportObject.importAsync = function enhancedImportAsync(...args) {
    if (memoizedError) {
      return Promise.resolve(function ErrorFallbackWrapper() {
        return ErrorFallback ? <ErrorFallback error={memoizedError} /> : null;
      });
    }

    return originalImportAsync(...args).catch((error) => {
      if (typeof error === 'string') {
        error = new Error(error);
      }

      if (typeof error === 'object') {
        error.isChunkError = true;
      }

      memoizedError = error;
      throw error;
    });
  };

  return loadableBase(loadableImportObject, {
    ...options,
    fallback: options.fallback ?? null,
  });
}

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.