This is great! Thanks for writing and sharing it. One thing looks wrong, though. You said, "React has been inspired by Redux." Maybe you meant that React.useReducer has been inspired by Redux? Or re-frame has been inspired by Redux? But I don't think React was inspired by Redux.

awesome. Does this change the equality/diffing performance characteristics?

specifically, when using the useLense idiom, to front useState... Is there a way to recover the performance benefits of using immutable clojure data that we get wrt using reagent/om?

@U056QFNM5 that was supposed to be read as "The React team has been inspired by Redux in creating React.useReducer". I can see why it's not being read that way though. I think your wording is an improvement, I will change it 😄

Actually, that sentence is fairly doubling anyway, so I think I can just delete the "has been inspired by" anyway.

@U050PJ2EU There is a useMemo which is fairly similar to the tool being used for swapping React's equality checking to rely on ClojureScript's instead of React's reference checking. I want to dig more into this though.

https://reactjs.org/docs/hooks-faq.html#how-do-i-implement-shouldcomponentupdate aha, this pretty much confirms what I thought 😄

well, the React.memo things is new to me, so it seems like "yes, and more!" is the answer.

useMemo will allow you to get performance gains for local state.

Interesting write-up, but something really stuck out to me that I'm surprised nobody else mentioned. You stated, "In reframing the object oriented paradigm of React into a functional programming one, some complexities are introduced." React is not and never was object-oriented and has embraced the functional paradigm from the start, which is exactly what attracted me to React in the first place. You also said that ClojureScript libraries try very hard to avoid classes. This is not a ClojureScript mentality, but straight from React and in the documentation to only use classes when you need to. The whole idea is that stateless components should be pure, which originated from React directly. The ClojureScript wrappers have the ability to create classes for those alternate cases so I'm pretty confused by your statement.

Also, as you mentioned in the post this is pretty much Redux, but built-in. It doesn't make it any less confusing on how to use it properly or avoid having to write custom reducers just to use it. I have thoroughly enjoyed re-frame's approach to this by using r/atoms and simply modify it directly and atomically. This basic and tedious procedure is not necessary with atoms.

@U09LZR36F Well, that's awesome news!

This could be a pretty good thing

Overall react is very functional, but classes provide state. The stateless component stuff has gone through plenty of iterations, and historically was based around classes. The method of using functions for stateless components has struggled to gain traction due to the fear that eventually they will become classes later. The clojurescript wrappers usually fall into a couple of traps when wrapping react classes. The methods of accessing state are more obscure than those of react, and because we're in custom territory, we can't rely on as much of the documentation provided by react itself, you are obscured through layers. Reagent has 3 forms of component, react is pushing for hooks to be the primary component form, so that would be 1 form to achieve the same job. That's the kind of win I'm celebrating here. I don't think reagent could have taken a different path, I just think the new place we're in is better.

@U050B88UR dominicm is looking into reference equality for react hooks. Sweet thread above ^

Regarding state, you're right. I expect a library to jump in and fulfil this need. I was trying to show the primitives that can be used. hx by @U4YGF4NGM has some hooks which are in this area, and I think they're really exciting.

@UAFT1B7Q8 React is not and never was object-oriented and has embraced the functional paradigm from the start, which is exactly what attracted me to React in the first place. @U09LZR36F was referring to the class-ful object-oriented-ness of react. They did buy into classes early in, which is a pain in the ass.

React is fairly object-oriented in its concept. The whole idea of a component instance is inherently object oriented

the tag-line v = f(state) idea is nicely functional, but the reality React is much more than that

even looking at reagent, no one would call that pure FP; you have all these implicit side effects happening in your functions!

the fact that you can use functions or classes is really just sugar

yeah... But hooks are still somewhat in the same boat

totally agree.

just cleaner

anyway, https://github.com/Lokeh/hx/ provides some custom hooks like <-state which returns an atom that will update your component on swap!/`reset!`, and <-deref which allows you to use global atoms similarly

Yeah, I'm pretty stoked about hx!

@U4YGF4NGM You're mixing up two different "object-oriented" meanings. Instances are not true object-orientation, but are what languages like Java call "object-oriented". Also, just because there are stateful components that does not make it object-oriented. As any functional language, library, or framework documentation will tell you, it's impossible to be 100% pure. That's just a reality due to the way the universe works and does not make it any less functional. The functional paradigm is an entire methodology and you're just looking at a part of an aspect of it.

I think you might be thinking in the Java-ism that OOP = classes

I'm not talking about OOP at all. You guys brought that into the discussion

ah OK, above you were commenting on the use of OOP in the article so that's what I was replying to. I may be wrong, but I think of OOP as constructing an application out of a graph of state-ful things that talk to each other. in that way, I think that React is nicely OOP. but so are most Clojure applications, and any kind of complex system (see: "microservices"). The reason I like Clojure so much is because it doesn't balk at that fact. I agree with you that React itself has done an amazing job of embracing FP idioms and ergonomics in the small. But at some point in the large, you want something other than just functions and values I think 😅 which React provides as well. I think that many CLJS wrappers try and paper over this OO in the large that React provides (see: Quiescent) and run into issues because of it.

at least now, React has a blessed way of eschewing classes with something a bit more formal than reagent's form-2/form-3 or rum's mixins.

So Rich's infamous talk, "The Language of the System" is perfectly fitting for what I was responding to regarding OOP.