loadable-components: Error "undefined is not an object (evaluating 'e[c].call')" When runtime chunk is slow to load

🐛 Bug Report

When the runtime chunk is slow to load, loadableReady will run regardless. This causes some errors (depending on the browser)

undefined is not an object (evaluating 'e[c].call') - Safari & Chrome Cannot read property 'call' of undefined - All browsers can't access property "call", e[c] is undefined - Firefox

To Reproduce

Steps to reproduce the behavior:

To replicate this I used express to serve JS bundles, allowing me to simulate it being slow to load

Slow down the bundle. I used this in my express routing

app.use('*/runtime~app.*.js', async (req, res, next) => {
  await new Promise(resolve => setTimeout(resolve, 5000));
  next();
});

Load the page in Safari 13 or 14 (seems to be the easiest browser to replicate)
See error

Note, the error only happens after loadableReady has completed and the hydration begins. This doesn’t happen if you don’t use loadableReady.

Expected behavior

loadableReady continues to wait for the runtime chunk to avoid the error

Link to repl or repo (highly encouraged)

Please provide a minimal repository on GitHub.

Issues without a reproduction link are likely to stall.

Run `npx envinfo --system --binaries --npmPackages @loadable/component,@loadable/server,@loadable/webpack-plugin,@loadable/babel-plugin --markdown --clipboard`

Paste the results here:

## System:
 - OS: macOS 10.15.5
 - CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
 - Memory: 4.76 GB / 16.00 GB
 - Shell: 5.7.1 - /bin/zsh
## Binaries:
 - Node: 12.18.0 - ~/.nvm/versions/node/v12.18.0/bin/node
 - Yarn: 1.21.1 - ~/.yarn/bin/yarn
 - npm: 6.14.4 - ~/.nvm/versions/node/v12.18.0/bin/npm
## npmPackages:
 - @loadable/babel-plugin: 5.13.0
 - @loadable/component: 5.13.2
 - @loadable/server: 5.13.1
 - @loadable/webpack-plugin: 5.13.0

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 3
Comments: 18

Commits related to this issue

fix: loadableReady should not resolve synchronously, fixes #634 — committed to gregberge/loadable-components by theKashey 4 years ago
Fix sync resolution (#651) * chore(tests): make breaking case for webpack4 * fix: loadableReady should not resolve synchronously, fixes #634 * chore(size): commit size change — committed to fivethreeo/loadable-components by theKashey 4 years ago
Fix sync resolution (#651) * chore(tests): make breaking case for webpack4 * fix: loadableReady should not resolve synchronously, fixes #634 * chore(size): commit size change — committed to 7rulnik/loadable-components by theKashey 4 years ago

Most upvoted comments

5.14.1 has been released 🥳

theKashey on Oct 22, 2020

@theKashey I modified the example and it would reproduce the error almost every time.

In this example , I have three js files: runtime, main, letters. If these files are loaded by the following order: main -> letters -> runtime, we will get the same error mentioned above every time.

I may find the reason:

https://github.com/gregberge/loadable-components/blob/c000d24eb9ca682dfe38403e838c5c5cbec46af3/packages/component/src/loadableReady.js#L53

loadableReady only checks whether the loadable required chunks are listed in window.__LOADABLE_LOADED_CHUNKS__, but can’t assure these chunks have already been loaded by webpack. Because letters has no relationship with main, so despite letters has not been installed, webpack runs main and loadableReady will resolve.

So if script files are loaded by following order, it will cause the error:

all the chunks listed in __LOADABLE_REQUIRED_CHUNKS__ are loaded after any of entry file and its dependent chunks, and runtime is loaded at last.

I think it will be solved if we can remove async in runtime’s <script> when getScriptTags.

iwyvi on Oct 21, 2020

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.

stale[bot] on Dec 21, 2020

In my fork i changed assetToScriptTag to

function assetToScriptTag(asset, extraProps) {
  const props = handleExtraProps(asset, extraProps)
  const { async, ...rest } = props

  return `<script ${async ? 'async' : ''} data-chunk="${asset.chunk}" src="${
    asset.url
  }"${getSriHtmlAttributes(asset)}${extraPropsToString(asset, rest)}></script>`
}

and then use

extractor.getScriptTags(asset => ({
   async: !!asset && !asset.filename.includes('runtime~app'),
}))

Obs not ideal, we should try and fix the core issue. But this stopped us getting errors for now

dr3 on Oct 20, 2020

Yeah disabling the runtime chunk meerly avoids the issue. There is still a larger issue. I still wanted to use the runtime chunk.

In my project I had to fork @loadable/server to make the runtime chunk not async (the rest still are), doing something similar to https://github.com/gregberge/loadable-components/pull/526

dr3 on Oct 19, 2020