Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is the best way to prevent failure to load component or catch properly? #961

Closed
sk-roofr opened this issue Apr 24, 2023 · 7 comments
Closed

Comments

@sk-roofr
Copy link

sk-roofr commented Apr 24, 2023

💬 Questions and Help

"webpack": "^5.75.0",
"@loadable/component": "^5.15.2",
I do not use ssr.

I am getting a lot of loadable-components: failed to asynchronously load component in my sentry. I am guessing it is because of the filename change on deploy, but I like to catch or prevent it so I can clean up the sentry. What is your recommendation?

Here is full error logs

TypeError: undefined is not an object (evaluating 'r[e].call')
{
arguments: [
{
message: undefined is not an object (evaluating 'r[e].call'), 
name: TypeError, 
}
], 
logger: console
}

loadable-components: failed to asynchronously load component [object Object]
{
arguments: [
loadable-components: failed to asynchronously load component, 
{
chunkName: [undefined], 
error: undefined is not an object (evaluating 'r[e].call'), 
fileName: [undefined]
}
], 
logger: console
}

Its also seem to get error on preload() with undefined is not an object (evaluating 'e.__esModule').

@sk-roofr sk-roofr changed the title What is the best way to prevent failed to asynchronously load component or catch properly? What is the best way to prevent failure to load component or catch properly? Apr 27, 2023
@sk-roofr
Copy link
Author

sk-roofr commented Jul 5, 2023

@theKashey Do you know how to handle it?

@theKashey
Copy link
Collaborator

You need to handle errors. Just put ErrorBoundary above loadable - https://loadable-components.com/docs/error-boundaries/ There is no other (supported) way.

The problematic part here is that loadable don't "own" errors - they are originated from webpack not being able load what it was expected to load, but this is webpack internal logic nobody else is aware of.

There could be an improvement related to easier detection of "loading" errors versus "runtime" errors, right now this information (STATUS_REJECTED) is not exposed.

@sk-roofr
Copy link
Author

sk-roofr commented Jul 6, 2023

What do you think about this approach? @theKashey

import loadableLib from '@loadable/component';

/**
 * Loadable component with ChunkLoadError handling
 */
const LOADABLE_STORAGE_KEY = 'page-has-been-force-refreshed';
export const loadable = componentImport =>
  loadableLib(async () => {
    const storage = window.localStorage;
    const pageAlreadyRefreshed = JSON.parse(storage.getItem(LOADABLE_STORAGE_KEY) || 'false');

    try {
      const component = await componentImport();

      storage.setItem(LOADABLE_STORAGE_KEY, 'false');

      return component;
    } catch (error) {
      if (
        (error.status === 'REJECTED' || error.name === 'ChunkLoadError') &&
        !pageAlreadyRefreshed
      ) {
        storage.setItem(LOADABLE_STORAGE_KEY, 'true');
        return window.location.reload();
      }
      throw error;
    }
  });

@theKashey
Copy link
Collaborator

What you want to do should be now possible via creating a custom wrapper around loadable, you are totally right here. But you cannot intervene into import this way - babel plugin will be quite unhappy.

Please play with the new babel configuration introduced at #966 to wrap internal logic with what you need.

@sk-roofr
Copy link
Author

Do you mean I should not pass import function and load inside of the wrapper? Unfortunately, I cannot use babel plugin

@theKashey
Copy link
Collaborator

If you are not using babel - then no worries at all. Your code would work. Just some pieces of loadable, like support for SSR, will not.

@sk-roofr
Copy link
Author

@theKashey Thanks for the answers! I will close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants