Documentation for SSR without Babel?

[Josh-Cena]

💬 Questions and Help

Hi, I'm trying to migrate Docusaurus from react-loadable to @loadable/component. Code-splitting is central in our architecture: every route component and its props are loaded as separate chunks. As of now, we use Loadable.Map to load the chunks needed for rendering each component. The chunk names and paths are generated on server-side as a registry.js file, before starting the bundler:

export default {
  // A chunk for a prop
  '001f469f': [() => import(/* webpackChunkName: '001f469f' */ '~blog/blog-tests/tests-blog-tags-blog-821.json'), '~blog/blog-tests/tests-blog-tags-blog-821.json', require.resolveWeak('~blog/blog-tests/tests-blog-tags-blog-821.json')],
  // A chunk for a component
  '010225af': [() => import(/* webpackChunkName: '010225af' */ '@site/_dogfooding/_pages tests/link-tests.tsx'), '@site/_dogfooding/_pages tests/link-tests.tsx', require.resolveWeak('@site/_dogfooding/_pages tests/link-tests.tsx')],
  // 600 more lines...
}

Where each chunk name maps to one loader, one webpack option, and one module option, which we can directly pass to Loadable.Map. There's another routeChunkNames file that maps each route to the chunks that need to be loaded. You can find the source code here, comments inlined: https://github.com/facebook/docusaurus/blob/main/packages/docusaurus/src/client/exports/ComponentCreator.tsx

We don't use the Babel plugin provided by react-loadable, because we allow users to swap out JS loaders, so they may not use Babel (or our Babel config, at least) at all. Instead, because we have our own codegen, dynamically generating thousands of lines of repeating code is not a problem.

My questions are:

• If I don't use the Babel plugin but choose to leverage our own codegen for generating the options that loadable needs (requireAsync, resolve, etc.), what are the API specs for those options? They seem to be internal and contain a lot of boilerplate, but we are happy to implement whatever loadable requires.
• Since there's no drop-in replacement for Loadable.Map, does that mean we have to implement our own equivalent with Promise.all, etc.?
• Does anything else do any static analysis, or would we be able to minimally tweak our current architecture (i.e. a centralized registry for all lazy-loaded chunks, and dynamically passing the options to loadable()) if we don't use the Babel plugin?

[stale[bot]]

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.

[Josh-Cena]

👋 No response yet!

[stale[bot]]

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.

[Josh-Cena]

👋

[stale[bot]]

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.

[Josh-Cena]

👋 Sigh is this project even maintained still? Is every such project dead?

[fivethreeo]

React.lazy is now in react 18, and works on the server.

https://github.com/reactwg/react-18/discussions/114

One thing that is missing is "Injecting Into the SSR Stream", should rewrite the babel plugin so we give a Promise to React.lazy no need for the component magic except for a chunkextractor on the server sidethat outputs the tags incrementally.

https://github.com/gregberge/loadable-components/issues/718#issuecomment-1292861738

[fivethreeo]

Seems like loadable-compnents has suspense support in client. Will give it a try with react 18 server side suspense and see.

[fivethreeo]

Copied this lazy from react 18, could be adapted to loadable https://codesandbox.io/s/react-18-custom-lazy-1liry3

[stale[bot]]

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.