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.

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.

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.