This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (35)
- # beginners (80)
- # boot (1)
- # calva (4)
- # cider (33)
- # cljdoc (40)
- # clojars (3)
- # clojure (95)
- # clojure-berlin (2)
- # clojure-europe (4)
- # clojure-italy (28)
- # clojure-nl (2)
- # clojure-seattle (1)
- # clojure-serbia (1)
- # clojure-spec (74)
- # clojure-uk (72)
- # clojurescript (29)
- # core-async (1)
- # cursive (80)
- # data-science (4)
- # datomic (17)
- # duct (75)
- # emacs (4)
- # figwheel-main (5)
- # fulcro (3)
- # jackdaw (1)
- # java (1)
- # jobs-discuss (20)
- # off-topic (32)
- # parinfer (2)
- # pathom (23)
- # re-frame (26)
- # reagent (25)
- # rum (6)
- # shadow-cljs (122)
- # speculative (4)
- # sql (17)
- # testing (7)
- # yada (8)
https://juxt.pro/blog/posts/react-hooks-raw.html I wrote this today.
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.
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.
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.
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
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!
anyway, https://github.com/Lokeh/hx/ provides some custom hooks like
<-state which returns an atom that will update your component on
<-deref which allows you to use global atoms similarly
@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.
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.
Hello again; Just wanted to mention that @tothda found a bug using Oz from the IClojure docker image, due to JVM version issues with a dependency. This has now been fixed in
[metasoarous/oz "1.5.6"]. Thanks again!
A new release (v0.0.3) of speculative, a collection of specs for the functions clojure.core. https://cljdoc.org/d/speculative/speculative/0.0.3/doc/readme Changes: https://github.com/borkdude/speculative/blob/master/CHANGELOG.md#003