React 17 + 18 support

[apepper]

Currently @loadable/component only supports react 16 is supported:

loadable-components/package.json

Lines 54 to 55 in cba6cab

	"react": "^16.12.0",
	"react-dom": "^16.12.0",

It would be great, if it would also support React 17 and the latest React 18.

[open-collective-bot]

Hey @apepper 👋,
Thank you for opening an issue. We'll get back to you as soon as we can.
Please, consider supporting us on Open Collective. We give a special attention to issues opened by backers.
If you use Loadable at work, you can also ask your company to sponsor us ❤️.

[stale]

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.

[apepper]

This is not stale. React 17 is still not supported:

loadable-components/package.json

Lines 54 to 55 in 73b17fd

	"react": "^16.12.0",
	"react-dom": "^16.12.0",

[partoneplay]

I use [email protected] and @loadable/[email protected]. They work well.

[azangru]

They work, but it shows a dependency conflict when installing packages with npm 7:

Please fix this 🙏

[stale]

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.

[IPRIT]

Still relevant

[stale]

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]

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.

[IPRIT]

1️⃣7️⃣

[theKashey]

1️⃣8️⃣

[mike-parkhomenko]

Hey! Is it possible to let us know approximately date for the next release with React 17,18 support?

Thanks)

[abhisharkjangir]

Is it supports react v18? I'm getting below error with

• "react": "^18.1.0"
• "react-dom": "^18.1.0"
• webpack": "^5.73.0"
• "@loadable/babel-plugin": "^5.13.2",
• "@loadable/component": "^5.15.2",
• "@loadable/server": "^5.15.2",
• "@loadable/webpack-plugin": "^5.15.2",

[reverofevil]

@abhisharkjangir No, it doesn't. The library is mostly dead for the last 2 years, except for a few fixes by @theKashey.

[azangru]

Now that the React team has stopped recommending loadable-components in their docs, does anyone know what the official blessed setup is? With React.lazy, webpack, server-side rendering, and all?

[reverofevil]

React 18 is a frontend library, it can't collect a list of dynamic imports that were awaited for during SSR. You can't do it with loadable components anymore, because it's incompatible. You can't do it with Vite SSR in dev mode, because it uses ESM and you can't hook calls to require there. I don't think there is any solution at the moment that actually works and might be used in production.

[azangru]

I'll just leave Dan's code sandbox here, from a comment where he said that React.lazy "just works" now. Perhaps this is what the recommended way of doing this now is.

[theKashey]

There is no recommended way of doing this and the majority of libraries(or react itself) are not working one way or another due to different reasons.

• the example from Dan will break on any ContextAPI update - [React 18] Selective Hydration fails hydration when using context api facebook/react#22692
• default examples from Loadable Components are failing since 16.10 due to change in Suspense - now you have to use it on server-side (before it will generate a problem)
  • non Suspense-based usage of Loadable-component is working

[vaukalak]

@abhisharkjangir I've created an example of usign loadable-components with react 18. It might be, that you were facing the same hydration issue before, due to differences in your server and client generated HTML. However now, with react 18 this actually creates an error, rather than just logging the warning.

[abhisharkjangir]

@vaukalak Thanks, I'll try if it works for me or not.

[fivethreeo]

React 18 with Suspense would be better if chunkextractor could have a reset method. Then we could use a custom writable in renderToPipeableStream that wrote the discovered components script tags as we render.

But loadableReady in the client cannot be used anymore so maybe write some script tags that say which modules will be loaded from those async script tags so we don’t try to refetch those during hydration.

If I understand all this correctly.

reactwg/react-18#114

https://github.com/brillout/react-streaming#injecttostream

[santicalvo]

Hello, I see there is a next release tag on this issue.

Is there a roadmap or a release date scheduled? Any branch for development?

Thanks a lot for this library!

[fivethreeo]

So decided to not use

https://github.com/brillout/react-streaming#injecttostream

Instead I did this

  let didError = false;
  let shellReady = false;

  class LoadableWritable extends Writable {
    constructor(writable) {
      super();
      this._writable = writable;
    }

    _write(chunk, encoding, callback) {
      // This should pick up any new link tags that hasn't been previously
      // written to this stream.
      if (shellReady) {
      }
      // Finally write whatever React tried to write.

      this._writable.write(chunk, encoding, callback);
    }

    end() {
      this._writable.end()
    }

    flush() {
      if (typeof this._writable.flush === 'function') {
        this._writable.flush();
      }
    }
  }

  const writeable = new LoadableWritable(res)

  const stream = renderToPipeableStream(<Html assets={{}}><App /></Html>,
    {
      onShellReady() {
        // The content above all Suspense boundaries is ready.
        // If something errored before we started streaming, we set the error code appropriately.
        res.statusCode = didError ? 500 : 200;
        res.setHeader('Content-type', 'text/html');
        shellReady = true;

        stream.pipe(writeable);

      })

https://github.com/fivethreeo/loadable-components-react-18

Will try adding loadabe-components soon

Clone and run

pnpm i
pnpm start

[fivethreeo]

Tried adding loadable components with streaming react and suspense. Did not work.

[fivethreeo]

Added support for streaming rendering with suspense here.

https://github.com/fivethreeo/loadable-components/tree/feature/server-side-suspense/examples/streaming-server-side-rendering

#889

[dglozic]

Any outlook for React 18 support in the near future?

[theKashey]

There is "real" React 18 support in works - #923, but I don't see any reason not to update package dependencies right away...

[dglozic]

I agree - people can upgrade to 18 and get the current code to work, while deferring the use of renderToPipeableStream and suspense until it is supported by loadable components. Actually, no, they can (and must) use it as renderToNodeStream is buffered in 18, but we can continue to render the App portion using renderToString while collecting loadables in SSR until full support is available.

[theKashey]

v5.15.3 has react dependency version changed

• from
  • "react": ">=16.3.0", which should work
• to
  • "react": "^16.3.0 || ^17.0.0 || ^18.0.0", which definitely works and more common in the ecosystem

[TwisterMc]

Did this happen? I don't see a v 5.15.3 in the releases and v5.16.0 says "react": "^16.12.0"

[chidev]

I agree - people can upgrade to 18 and get the current code to work, while deferring the use of renderToPipeableStream and suspense until it is supported by loadable components. Actually, no, they can (and must) use it as renderToNodeStream is buffered in 18, but we can continue to render the App portion using renderToString while collecting loadables in SSR until full support is available.

Any idea how we can get React 18 and Loadable to work correctly? Just some general steps / direction would be greatly appreciated.

[dglozic]

We are using Loadable just fine in React 18, what's the issue? We (IBM) are currently using the latest loadable-components with React 18.2 and Loadable works fine (we are doing as explained above - rendering the App porting using renderToString, collecting loadables in SSR and then rendering the envelope using renderToPipeableStream).

[azangru]

We (IBM) are currently using the latest loadable-components with React 18.2 and Loadable works fine (we are doing as explained above - rendering the App porting using renderToString, collecting loadables in SSR and then rendering the envelope using renderToPipeableStream).

Any reason why you prefer this over React.lazy?

[dglozic]

SSR. We use Loadable since React16 and needed it for server side rendering. For the client side, Lazy is fine. Obviously React has this new approach for SSR in 18 with Suspense and Server Only components but this is still early and they apparently let the likes of Next.js and Remix to take the lead and define what SSR should look like with Suspense. We are waiting for that dust to settle and continuing to use Loadable as explained above.

[azangru]

I just wanted to put it out there that React.lazy works fine with SSR without any requirement for Next, or server components, or anything like that. I'm using it with my custom (i.e. non-next) SSR setup. There's a minimal demo linked to in a comment above.

[theKashey]

Unfortunately using Lazy, or better to say - relying on Suspense does not work in many case.
The problem is - any update to the context above Suspense will trigger it into loading mode, so you will lose not yet hydrated content - facebook/react#22692

That's it - your app is expected to be "dead" until hydration is complete and loadableReady is a way to understand when it's the right time to move forward.

This is not a "code splitting" library, this is "code tracking" library. That something Lazy does not do

[salihovdr]

We are using Loadable just fine in React 18, what's the issue? We (IBM) are currently using the latest loadable-components with React 18.2 and Loadable works fine (we are doing as explained above - rendering the App porting using renderToString, collecting loadables in SSR and then rendering the envelope using renderToPipeableStream).

Can you share a basic example in code? Really curious about this part: "rendering the App porting using renderToString, collecting loadables in SSR and then rendering the envelope using renderToPipeableStream).
"

[dglozic]

Unfortunately there is too much code in too many places to distill into a simple example. Let me try in words:

1. We use SSR to render the server-side state of the root React element into a string buffer.
2. We then render the overall page with the common header, static parts etc., using the computed stats from the first render pass (CSS, JS etc.). This render is using pipeable stream.
3. When we do (2), we keep the pipe open so that API calls we made before (1) can complete.
4. As the API calls are completing, they append the result of the call as JSON elements to the stream.
5. On the client, as JSON elements with API call results arrive, we aggressively grab them and render the components that need them.
6. Pipe closes.

Visually, it looks great - normally the first render is in under 200ms, and entire page is done rendering in under 500ms, even with multiple API calls done to fetch necessary metadata.

While we are watching Server Only Components and Suspense story evolve, we don't want to commit to Next.js or Remix to get them.

[salihovdr]

@dglozic is that an internal company solution or was is based on an existing blueprint? I've been looking into using renderToPipeableStream without next.js and Google led me to this thread.

[dglozic]

It is internal, yes. But it is not hard to reproduce. It is also kind of interim because some proposals to support stats with streaming didn't yet make it into loadable-components (hence the initial render to a buffer to get the stats computed the old way). I keep hoping that @fivethreeo has put together would get merged :-).

[salihovdr]

Gonna take a look at that example. Thank you!