React 19 support

[ThomasGreenspan]

Is your feature request related to a problem?

I am trying to integrate this into a webapp that is built on react 19 and running into errors.

The error on import:
Cannot read properties of undefined (reading 'ReactCurrentOwner')

Alternatives you've considered

Possible workarounds:

• Support a subset of the app in react 18 while the rest stays on React 19
• Convert the entire app to react 18

Both of these are options I have started looking into but they both seem quite painful. Would love this library to support react 19 natively if possible.

Any chance this will get looked into?

[axelboc]

Hey @ThomasGreenspan, it's on our list of priorities to investigate for the next couple of months. I don't think we have any blockers at the moment, dependency-wise so I'm hopeful. 🤞

[ThomasGreenspan]

That's great to hear!

Perhaps also worth noting, I am currently trying to run on nextjs 15+ with an app router. I think the issues come from the react 19 compatibility (which the app router uses) but when looking into adding support, it might be worth also checking compatibility with nextjs app router.

[axelboc]

I'll release a beta either way so you can test, but I'll try to also create a new code sandbox for NextJS. Thanks for the suggestion!

[ThomasGreenspan]

Thanks! Let me know here when that beta is available, I'll definitely be interested in trying it out.

[axelboc]

Quick update: if everything goes well, we'll soon do one more release of H5Web with React 18 so people can get all the latest developments without upgrading right away — this will hopefully be the last version with React 18. Then, we'll do a release specifically for React 19 soon after (with a beta release first as discussed).

[axelboc]

if everything goes well

It's not going well... 😓 I'm facing multiple issues upgrading to React 19.2:

• StrictMode is causing issues with the R3F visualizations in development that I can't pinpoint (even in the mock demo).
• The UI gets stuck on the Suspense loading fallback when slicing through a stack and in a few other cases.
• Every time a Suspense loading fallback is shown, it remains visible for at least 300ms, which considerably slows down everything (including the explorer sidebar).

The "legacy throw" technique that we use to integrate with Suspense is supposed to still be supported, but it doesn't seem to be the case in practice...

I tried switching to the new use hook, but it's a whole different paradigm. Every promise (i.e. including every async function call) has to be memoised. Every promise-throwing synchronous function has to be made async and return a promise instead of throwing it. I don't like all the complexity that this adds to the codebase, not to mention that it solves only the stuck Suspense fallback issue anyway...

The 300ms issue is reported here: facebook/react#31819 — it's a conscious design decision by the React team and there doesn't seem to be a way to bypass it except by hacking the React code itself with a Vite plugin...

So... not sure where to go from here to be honest. 😭

[ThomasGreenspan]

Hey, sorry to hear that it's not as easy as hoped. Have you made any progress since this last update? I assume there's going to be increasing pressure to make this upgrade beyond me so hoping you're still looking into it. I can't really help this month but could possible try and help afterwards if you need an extra pair of eyes.

[axelboc]

I can share a couple of updates:

• React Three Fiber published a release last week that fixes the visualizations going blank in some cases (but not all). The Suspense issues remain, though.
• The 300ms issue can be worked around with a hacky Vite plugin, so even though it's still very much puzzling to me, I'm not too worried about it.
• The main, most visible problem is when slicing through a dataset. As mentioned, the Suspense boundary gets stuck for a while, and then when it finally renders the visualization with the loaded data, the visualization flashes and goes blank. Sometimes the app also becomes janky because of huge regular garbage collection cycles, which points to a significant memory leak. You can check this out for yourself with branch sandbox_react-19_base, which contains the minimum required migrations for the app to start with React 19.2 (useRef, context providers, etc.)
• In sandbox_react-19_use, I made an initial attempt to migrate to the new use hook. It somehow feels a bit smoother, but the same issues remain. Not to mention that memoising promises correctly is a nightmare (which is probably partly why it's not working)...

I'm feeling a bit frustrated that the React team broke the legacy promise-throwing technique without providing any advice or tools to migrate away from it. I feel like I'm not properly equipped to hunt down the cause of the various issues I'm seeing, let alone to understand them. I don't even quite get how to use the new use hook without going mad, especially since React hasn't yet provided a helper to memoise promises in front-end apps...

My feeling right now is that we need to migrate to a library like Tanstack Query or the like that does things like React wants internally, or to migrate away from Suspense completely, but both options feel really daunting.

[wiwski]

@axelboc while digging a bit into this issue I found this React doc (currently in progress) about :

how React leverages promise.status, targeted at Suspense-enabled libraries

reactjs/react.dev#8125

This probably won’t remove the 300ms minimum fallback behavior itself, but it might help avoid some unnecessary suspends / microtask fallback flashes by allowing React to synchronously read already-settled promises.

I made a fork with a minimal addition to react-suspense-fetch.ts to experiment with this approach:

https://github.com/wiwski/h5web/tree/sandbox_react-19_use-promise-with-status

So far it doesn’t seem to change much, but maybe it can help narrow things down or serve as a starting point for further experiments.

Happy to help further if needed — we’re looking to use the viewer in https://github.com/betagouv/euphrosyne to display HDF5 data for New Aglae particle accelerator users, so we’re quite motivated to help move React 19 support forward 🙂

[axelboc]

Thanks a lot for experimenting as well! I did play with this a bit as well and even looked into the React codebase a bit. From what I understand, the use hook takes care of managing this status property internally. And if the status isn't set, React falls back to the "legacy throw behaviour". But as you said, so far my experiments haven't been very successful...