React 18 support plans

[tomconnors]

There have been a number of discussions about problems using Reagent with React 18. The main issue seems to be that cursors in some <input> elements jump around, and the root cause is probably related to the fact that Reagent and React 18 both implement update/render batching, in ways that presumably are not compatible.

Do Reagent's maintainers have plans to fix these issues and "officially" support React 18, or should users assume that Reagent will be best used with React 17 for the foreseeable future?

[Deraen]

You can also use React 18 with the old compatibility mode, though it will be similar to just using React 17.

While a few others have maintainer rights to the repo, effectively, I've been the only one maintaining Reagent for the last few years.

I don't have any plans to make any significant changes to Reagent, and any meaningful improvements to React compatibility would require significant changes.

The biggest reason is that UIx is so close to being a perfect React wrapper that there is little reason to try fixing Reagent. Fixing the problems in Reagent would be just as breaking for users as switching to UIx, and the resulting lib would look the same as UIx, so I don't see value in trying to make the changes to Reagent.

Important choices in UIx:

• I now think defc macro to create the components is a superior choice to trying to use regular functions and then wrapping them in runtime
• Using a macro ($) to create the elements vs. using Hiccup style data and compiling to React elements in runtime
• Using hooks as a foundation for state management and interop with RAtoms and Re-frame (use-subscribe) hook (Reagent has to do lots of magic to set up the state for each component to handle RAtoms.)

(Helix also looks great, but I mostly have experience with UIx.)

I should probably mention the plan (or lack of it) and these points in the readme, but I'm not sure of the wording yet. Or maybe I'll link this discussion.

[Deraen]

I should also write a proper summary/explanation of the problems of making Reagent compatible with React 18 concurrent mode.

Runtime component wrapping and element compilation aren't directly problems preventing the React 18 support. I think they make Reagent worse than the alternatives, so there is less interest (for me) in working on Reagent.

The biggest problem is indeed how the React batching / concurrent mode works together with the Reagent RAtom update / render queue. I already wrote a post about this in 2022: https://www.metosin.fi/blog/reagent-towards-react-18

#504

Just removing the queue in Reagent should be easy; it just breaks the test suite, and I fear it could cause hard-to-debug problems in the applications too.

[tomconnors]

Thanks for the detailed reply. I've been using Helix in an existing Reagent app and it works well, but a full migration to UIx or Helix is daunting - there's just a lot of Reagent code to change, and some r/atom-based code doesn't trivially translate to react hooks. I wonder if it would be helpful for Reagent or a new lib to offer an easier migration path: offer the same syntax and most of the same API as Reagent but remove the things that are incompatible w/ React 18.

[Deraen]

Perhaps. I've considered something like that, but, e.g., changing how the Ratoms work could break apps even if the code/API is compatible. Making the Ratoms work over hooks can be problematic because the rules of hook use are quite different; you can't use hooks inside looks or conditions, which is fine when dereferencing Ratoms.