Migrate from react-loadable to loadable-components (or other alternatives)

[kvnxiao]

Currently, with react-loadable:

• react-loadable doesn't seem maintained anymore, just take a look at the "issues" list (open PRs for multitudes of fixes) dating back to 2018 https://github.com/jamiebuilds/react-loadable/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc
• react-loadable does not support React 17.X.X due to it still referencing the deprecated and now removed/to-be-removed componentWillMount:

   react-dom.development.js?61bb:67 Warning: componentWillMount has been renamed, and is not recommended for use. See https://reactjs.org/link/unsafe-component-lifecycles for details.
  
   * Move code with side effects to componentDidMount, and set initial state in the constructor.
   * Rename componentWillMount to UNSAFE_componentWillMount to suppress this warning in non-strict mode. In React 18.x, only the UNSAFE_ name will work. To rename all deprecated lifecycles to their new names, you can run `npx react-codemod rename-unsafe-lifecycles` in your project source folder.
  
   Please update the following components: LoadableComponent
  

💥 Proposal

I haven't dived too deep into the Docusaurus codebase but it seems like even according to the official React docs here https://reactjs.org/docs/code-splitting.html#reactlazy, the recommended loadable in React with code-splitting support and SSR is loadable-components https://github.com/gregberge/loadable-components, which seems like something that should be moved towards to allow easy support of newer React versions.

Perhaps there are also other alternatives if the above mentioned one isn't ideal for whatever reason. Opening this issue for conversation on this topic.

Have you read the Contributing Guidelines on issues?

Yes

[slorber]

Thanks

You are right that we should find a future-proof solution to this problem.

It does not look so simple to do that switch, but it's on my plans to look at all this and ensure that we rely on modern/well-maintained deps that keep up with new React versions.

[hustcer]

+1

[slorber]

FYI next version will use React 17 by default, and I've published a fork of react-loadable to get rid of the dev deprecation warning.

#4218

We'll still have to migrate or find a solution to support React 18 though so I'll keep this issue open

[slorber]

Next.js 13.x + Webpack is apparently also using a fork of react-loadable: https://github.com/vercel/next.js/blob/canary/packages/next/src/shared/lib/loadable.tsx
(I think they use Rust code when Turbo is enabled)

Today loadable-components does not look super maintained: few commits, and their docs still mention that React does not support Suspense for SSR/SSG, while it does now. But it looks like it may support Lazy better than our current solution: gregberge/loadable-components#925

Are there good reasons to actually migrate anymore? It looks like we'd have to build/maintain our own fork or custom solution (like Next.js) in the future, and there's no more mainstream open-source lib to do that.

[shaharkazaz]

@Slober I've just updated to docosaurus v3 and saw that the following error fires a ton:

Kind of hard to see actual error while working in dev

[slorber]

The react-loadable warning is due to React v18.3 release outputting new warnings to prepare us for React v19.
https://react.dev/blog/2024/04/25/react-19-upgrade-guide

Already fixed here but not released: #10079

Until it gets merged/released, revert to React v18.2

[slorber]

FYI I'm going to close this for now.

I'm still maintaining/upgrading our react-loadable fork here: https://github.com/slorber/react-loadable

It should now be compatible with React 18.3 / React 19, and the code we use is relatively small so that I'm confident I'll be able to keep it up to date in the future. More info: jamiebuilds/react-loadable#213 (comment)

---

I don't think loadable-components is the right choice either. It's not super well maintained and is tightly coupled to Babel/Webpack from which we are likely to move off at some point. If we ever implement something, it's likely to be our own custom solution (Next.js kind of does this too, using internal code inspired from loadable-components).

Also, it's very possible that using React Server Components (tracked in #9089) will reduce the need for such a solution in the future since our code-splitted route components will now become RSCs. I'd prefer to wait until we support RFCs and see if we still need such a library.