I've used React a lot, but only via Reagent in ClojureScript.
I think the JS people are being scammed.
Before at least I knew what was called on boostrap moments. Now everything is run as a side effect when any dependency change. My needs on checking if a prop or a dependency has changed hasn't evolved at all. I just have the core of my side effects on useEffect.
There’s not much of a cognitive difference between “defining a reagent component which uses ratoms and calls a pure function that derefs, updates or swaps them”, and “defining a react functional component that uses hooks”. It looks weird to have the “atoms” inside the render function instead of outside, and there are the aforementioned limitations (“the rules of hooks”), but it’s a compromise to get the feature into JS React in a consistent, performant manner.
I’d love to use CLJS/Reagent or even go full re-frame on our front-end codebase, but that’s a hard sell at my company since I’m the only dev who’s ever played with Clojure.
In fairness, the JS world has never had well engineered OOP GUI toolkits like you find in the desktop space. If you've never used JavaFX then ReactJS probably seems pretty magical. If you have, then, well ...
ClojureScript is a functional language.
Reagent is a ClojureScript wrapper over React.
Cljs + Reagent is AWESOME.
There is a JavaFX wrapper too, with a similar API.
The comment was in response to "that's bonkers". And that has been my reaction on learning stuff like React and derived frameworks. A lot of it looks like functions for the sake of it, when objects already solve those problems but became unfashionable.
But here's the weirdness. useState knows whether it's already been called for a given component; this is how it tracks state. The first call returns the state (the initial value) and a setter. Subsequent calls -- occurring after the first render -- do not return these objects anew, but instead reach into a per-functional-component store and return the values that already exist there. Calling the setter doesn't set the state in the body; rather, it updates the value in the store, then triggers a re-render.
If you're wondering just how react knows how to match up calls to useState between renders, it doesn't really. It simply matches them up based on the order they're called in. For that reason, you have to always call exactly the same useState calls on each render -- no putting some in an if statement or a variable length for loop, otherwise they'll be out of sync.
There are a bunch of other "hooks" for use in functional components, but they all work basically the same way: place some data in the functional component's store, then set up re-render (which, again, just means calling the component's function again) to occur when certain data changes.