Import component dynamically. WebpackError: TypeError: Cannot read property 'call' of undefined

[nkosakul]

Hi!

First, thanks for the plugin! Really cool!

I´m using @loadable/component for a portfolio website with Gatsby + Contentful.
Its working great with Gatsby version 2.20.36, but as soon as i update Gatsby to 2.20.4 or higher, which i do because of the incremental build feature i want to use, its failed on build.

I´m using gatsby-plugin-loadable-components-ssr v2.0.0

The Error i get is WebpackError: TypeError: Cannot read property 'call' of undefined.
The Error comes up, while gatsby is building the html pages

My Code:

import loadable from '@loadable/component';

...


page.elements.map((element) => {
  const typename = element.__typename.replace('Contentful', '');
  const Component = loadable(() =>
    import(`../components/${typename}`)
  );
  
  return <Component props={element} key={element.id} />;
})}

gatsby-config.js looks like this

{
      resolve: `gatsby-plugin-loadable-components-ssr`,
      options: {
        // Whether replaceHydrateFunction should call ReactDOM.hydrate or ReactDOM.render
        // Defaults to ReactDOM.render on develop and ReactDOM.hydrate on build
        useHydrate: true,
      },
    },

I´m new to gatsby and its my first time using it with contentful, so sorry if its a dumb question.

Here is also the link to my repo
https://github.com/nkosakul/pepita/tree/develop

[nkosakul]

A Screenshot from the console:

[hector-del-rio]

The link you posted to your repo cannot be build because it uses data from Contentful. It is hard to tell what could be going on without a minimal repo to reproduce the error.

[nkosakul]

oh sorry, you're right.
you can't build without an .env with the API keys..
would it help if I generate an temporary API key and DM it to you, so you can build the files?

[hector-del-rio]

Maybe it's best if you switch to JSON data source in a different branch.

[nkosakul]

Ok, so i created a new branch source-json where i´m sourcing the data from a json file, instead of contentful. I made the branch as simply as i could and build the data similiar to the contentful response.
I get rid of all the other pages, so the index.js is now the only page which is being created.

on yarn start everything works great. On build its throw out the same error above.

Here is the link:
https://github.com/nkosakul/pepita/tree/source-json

Thanks for your time, i appreciate it  🙏🏻

[hector-del-rio]

I spent almost the whole day yesterday trying to figure out what the problem is. I tried debugging gatsby's build process. There seems to be some problem with how the modules are loaded, but I can't figure out exactly what.

It would be really helpful to find what version of gatsby was still working, but when I tried 2.20.36 as you mentioned, it didn't work either. Could you let me know if you find a version that works?

[nkosakul]

Ok, thats weird.. now it doesn´t work for me either.
I also throw everything out except for the files, that we really need (pushed to source-json branch).
I even created a whole new repo on a different machine and it doesn´t work too..

I did some testing, maybe its helping:
On develop, if i go back to the commit, before i bump up gatsby, its still working.
So i just copied the yarn.lock file (i know, i shouldn´t) from there and push it to develop.
And see there.. build is running fine again.
But (of course), if i let yarn re-create the lock file.. build its failing again.

(The file, where everything works fine: https://github.com/nkosakul/pepita/blob/test/yarn.lock)

I´m super confused

[hector-del-rio]

Ok, that yarn.lock was useful 👍

Adding the resolution below in package.json will fix the issue for now

"resolutions": {
  "@babel/core": "7.8.4"
}

Now I only need to figure out what has changed between the two version of babel.

[nkosakul]

I´m glad that helped! And thank you!

This fix seems to fail at the first build, when there is no .cache folder,
but every other build after the first build is running clean.
(With: gatsby 2.20.4, gatsby-plugin-loadable-components-ssr ^2.1.0 and with resolutions added to the package.json)

So for me, netlify will still fail to deploy.
So i might gonna wait for now. 🤔

[krichdev]

I am getting this same error.

gatsby: "^2.22.15"
"@loadable/component": "^5.12.0"
"gatsby-plugin-loadable-components-ssr": "^2.1.0"

I am also using contentful to source data and getting error on build-html process of WebpackError: TypeError: Cannot read property 'call' of undefined

[MastaAaron]

Any hope for getting this resolved? I'm also experiencing the error...

Versions installed:
gatsby@2.24.8
@loadable/component@5.13.1
gatsby-plugin-loadable-components-ssr@2.1.0
@babel/core@7.8.4 (via "resolutions" entry in package.json)

[StrategyLLC]

We are getting this same error. We are using WordPress as our data source, but the code looks exactly the same as what was posted. Using latest versions. Anybody have any insight to this issue outside of what has already been posted?

[ashhitch]

Same for me. I tried taking a fork of the repo and updating the dependencies but it did not help. (was hoping for an easy win!)

[SimeonC]

Looks like this issue in the main repo is related; gregberge/loadable-components#599

The only way I managed to get around this was by removing the dynamic imports - basically, instead of passing the component name/path as a string I write the whole loadable(() => import and pass that instead.

[MaxBoltik]

any news?

[MaxBoltik]

Looks like this issue in the main repo is related; gregberge/loadable-components#599

The only way I managed to get around this was by removing the dynamic imports - basically, instead of passing the component name/path as a string I write the whole loadable(() => import and pass that instead.

Could you please explain a bit more about "I write the whole loadable(() => import and pass that instead."

[SimeonC]

So instead of `<DynamicLoader file=“filename”>` I ended up writing something like `<DynamicLoader loadable={loadable(() => import(‘path/to/filename’)}>` Don’t know how helpful that would be for you, it’s not as clean as what we’d like but it works. Basically you hardcode the loadable components and dynamically select them instead of using a dynamic import.

[MaxBoltik]

I've found another workaround.

Wrapper for dynamic component like this:

import React from 'react';
import loadable from '@loadable/component';

const ProxyComponent = (props) => {
  const Loaded = loadable(() => import('./Component'));

  return <Loaded {...props} />;
}

export default ProxyComponent

A map for component list:

import ProxyComponent from './ProxyComponent';
//...other imports

export default {
  'ProxyComponent': ProxyComponent,
  //...other components
};

And eventually use this map where I need this dynamic component:

const componentName = 'ProxyComponent';
const SomeDynamicComponent = proxyMap[componentName];

  return (
    ...
      <SomeDynamicComponent />
    ...
  );

It works in SSR as a static and in SPA as a dynamic.

[abahari]

Hello Everyone,

I solved this problem by adding the following condition:

let DynamicModule = null;
const windowGlobal = typeof window !== 'undefined' && window;
  if (windowGlobal){
    DynamicModule = loadable((props) => import(`../components/${props.module}`));
  }

and before calling this module, check if DynamicModule exists :

{
   DynamicModule && <DynamicModule module={`your module name`} />
}

I hope this help

[alesanchezr]

Same issue here, I'm only loading icons so for now I'm just ignoring the icons during SSR

import React, { useEffect } from 'react';
import loadable from '@loadable/component'
import PropTypes from 'prop-types';

const Icon = ({ icon, ...rest }) => {
    if(typeof(window) === 'undefined' || !window) return "";

    const Comp = loadable(() => import(`./set/${icon}`))
    return <Comp {...rest} />
}
Icon.propTypes = {
    icon: PropTypes.string.isRequired,
    color: PropTypes.string.isRequired,
}
export default Icon;

[lunelson]

I'm getting the same error here with gatsby 2.28.2 and this plugin 2.1.0. I'm also using the pathPrefix option, which might be relevant. The solution of using the resolutions field in package.json, as mentioned further up this thread, didn't work for me.