Loadable-components: Was getState() replaced or removed; is it now built in behavior?

[bigwoof91]

Trying to continue using window.snapSaveState = () => getState(); with the new version @loadable/components, and it seems to not be a module export anymore.

I have a purely static react app and have been using react-snap in conjunction with your guy's beautiful getState :)

How should I continue to maintain this functionality with @loadable/components?

[gregberge]

Hello @bigwoof91, I don't know exactly what is your need. But I think you want to know which modules are required. You should take a look inside https://github.com/smooth-code/loadable-components/blob/master/packages/server/src/ChunkExtractor.js and try to call the internal methods you need.

Tell me what do you need exactly, then I can expose it publicly and document it!

[bigwoof91]

@neoziro I'll try to explain (though I am a bit ignorant):

So I am using react-snap and I came across one of their known caveats:

Since I am not using SSR, I am using snapshot... in order to provide the site with sufficient search engine crawling, etc. And the loadable-components (earlier version) library provides a getState() function so it can be stored in a window object window.snapSaveState.

I will look in ChuckExtractor.js right now, for a similar (or the same) method. Can you advise a method that exists in this project, the achieves the same behavior as getState(). I will let you know if I find what I'm looking for, if I catch anything before you respond.

[MacKentoch]

@bigwoof91 you may need to have a look here too:

• https://github.com/smooth-code/loadable-components/blob/master/packages/server/README.md#3-setup-chunkextractor-server-side
• https://github.com/smooth-code/loadable-components/blob/master/packages/server/README.md#4-add-loadableready-client-side

[MacKentoch]

Alright let's be realistic and don't expect real help from react-snap and from loadable-components.

getState() was introduced for static website rendering to avoid first load blink.
That was great way to create static website with dynamic loading.
But loadable-components evolved exclusively just for server rendered websites to be the library for React.lazy.

If you want to create pre-rendered static website with dynamic loading don't waste your time (sad but true...): just leave loadable-components and reactsnap and go something like Gatsby.js.

[stereobooster]

If we would drop the tone, there is a sense in those words.

Alright let's be realistic and don't expect real help free labor from react-snap and from loadable-components people on the internet who don't owe you anything.

Yes, this is open source. People provide you with results of their labor for free without any warranty or further promises. You can use, you can skip it. It is up to you.

If you want to create a pre-rendered static website with dynamic loading don't waste spent your time (sad but true...): just leave loadable-components and react-snap and go something like Gatsby.js.

Right, and you can spend your time to learn GraphQL (which is good in long-term, I guess, but will slow down you in the beginning) and spent some time writing transformation layer from the existing data source to Gatsby's GraphQL.

---

Gatsby is a great tool and if you can use it (like you already know how to use it), go ahead and use it. From my experience, it has some barrier for novice users, like GraphQL and a need to write custom plugins to work with your data.

React-snap is for a different purpose, it is for the case when you already have some codebase and don't want to invest time to rewrite in Gatsby or react-static or ...

As of loadable-components, I use the previous version which has getState(). My hope is that eventually we will not need any external solution and will be able to use React.lazy, which is not the case right now.

I tried:

const RootApp = (
  <ConcurrentMode>
    <Suspense fallback={<div>Loading...</div>} maxDuration={5000}>
      <App />
    </Suspense>
  </ConcurrentMode>
);

if (rootElement.hasChildNodes()) {
  ReactDom.hydrate(RootApp, rootElement);
} else {
  ReactDom.render(RootApp, rootElement);
}

and

const root = ReactDom.unstable_createRoot(rootElement);
root.render(<Suspense fallback={<div>Loading...</div>} maxDuration={5000}><App /></Suspense>);

The code above results in white flash (blink), but logically it shouldn't

[MacKentoch]

@stereobooster please read the issue since the beginning and stop taking issue for your own.

Do you find answers helpful?
Is issue not clear enough?

Now concerning my last comment: did I mention persons or repositories?
When someone says something like: I dislike ReactJS or any library,

does it mean he spits on people behind react?

I make a distinction between repositories and persons (I reply to you since I target you to bring you more information and not raging).

I spent a lot of time to try to fix a dropped feature. Not only for me but trying to help in case I found the fix. I'm not raging. But truth is this is clearly a waste of time since it can't work anymore (and you confirmed this again sadly for us all).

It shows it is better to stick to backed to (safest) solutions rather trying mixing libraries that drops feature here and there.

[stereobooster]

Keep in mind that right now is period of transition and some parts of the ecosystem are still behind. React implemented React.lazy, but they didn't implement SSR for it and loadable-components tries to fill in the hole (and it accomplishes the task). The second part is that concurrent mode doesn't suppose to erase existing HTML or at least it should wait until all components get loaded before it will erase everything. And it is possible to report this to React, but they can rightfully say that this is not implemented yet - those features marked as unstable (unstable_createRoot, unstable_ConcurrentMode). And as React team always say, there is no need to immediately migrate to the latest features. So I don't understand what the issue - use the previous version of loadable-components until React will fix the issue (stabilize ConcurrentMode).

This is normal for React - they implement a new feature it takes some time for the rest of ecosystem to catch up, no need to abandon all the solutions because they didn't catch up, you can use previous versions (unless there are security holes)

[gregberge]

I understand your disappointment, to be clear, working on these feature is not my priority. I don't know how react-snap works, it is not my use-case, so I will not implement it. However, if someone want to dive in and work on it, I am OK. Also guys, please don't fight, it doesn't help!

[stereobooster]

Here are options for anyone who will face this issue:

• use [email protected]
• wait for React's ConcurrentMode
• use unstable_ConcurrentMode (at your own risk). Here is full example https://github.com/stereobooster/react-async-issue
• create PR for @loadable/component, which will add back getState

[gregberge]

Good summary, I vote for option 4!

[theKashey]

There is a solution for any loader, which could expose loading promise, or prefetch.
This interface probably would not work for loadable due to _full-import_ support, and different ways to do _prefetching_.

Probably doable via createLoadable ie custom render function, but it's not exposed now.
If one would let configure render, and also expose promise among arguments - then it would work like:

// like
const AsyncLoadedComponent = loadable(() => import('./deferredComponent'), {
  render: ({Component, promise, props}) => {
    <PrerenderedComponent
     live={promise} 
    >
       // display component when JS is loaded and promise resolved
       // display SSR-ed HTML utill then
      < Component {...props} />
   </PrerenderedComponent>
  }
});

PS: All this stuff was here prior v4 😞

[gregberge]

getState is now not a priority. I think users are moving forward with Gatsby and other solutions.