3 ms·

I think that hooks and Reagent developed somewhat independently; or at least, they are not as related as one might think at first glance. The primary differenc

I think that hooks and Reagent developed somewhat independently; or at least, they are not as related as one might think at first glance. The primary difference is where the data _flows from_. Like another commenter pointed out, your examples can be done similarly as trivially with Hooks. The difference is that the state is stored in Reagent in a global mutable atom, while the state in React is stored in the React tree, and is tied to the render lifecycle. This doesn't seem like a huge difference on its face, but in practice it makes for very different experiences navigating a code base. In Reagent, your data is flowing down via props but also from the side via any number of atoms/subscriptions/etc. In React, you know that your data is always either state local to the component or passed via props. This isn't even to mention the other various hooks like useEffect, which allows you to coordinate side-effects with changes in data in a composable, locally-scoped way that Reagent does not allow you to do. In order to coordinate side effects, it requires you to keep the description of side effects completely separate from your components, which makes them less composable. For people who enjoy the way that React Hooks makes you think, and are also interested in ClojureScript (immutable data structures + amazing standard library + hot reloading + macros built into the language), check out https://github.com/Lokeh/hx https://github.com/Lokeh/hx or its WIP successor, https://github.com/Lokeh/helix https://github.com/Lokeh/helix (I am the author of these libraries).

filoeleven 7y ago
I have a tangential question for you about helix. You switched from hiccup-style lists in hx to functions in helix.dom. I was just looking at fulcro and they made a similar choice. What drove that decision for you? One of the things that first drew me to check out reagent and hx was that the components are declared as data. I haven’t tried any of these libs out yet, so while hiccup syntax looks to me to be more idiomatic clojure, there must be solid, practical reasons for implementing them as functions that I haven’t understood yet, and I’m curious to hear more about what they are.
- lilactown 7y ago
  Performance, primarily. Hiccup that is generated _at runtime_ is incredibly wasteful; you allocate a bunch of immutable vectors and maps, then parse them into React elements and throw them away, every time your component is rendered. This is a constant performance tax on your application and makes Reacts tradeoffs re: virtual DOM worse. React Elements are already data (they are POJOs), so you lose nothing in terms of declarative-ness using hiccup vs. functions/macros. If you're very attracted to hiccup syntax, you can still use hx's hiccup parser with helix (docs incoming) or try out a library I wrote called thump[0], which uses reader tags to parse the hiccup at compile time into React Elements. 0: https://github.com/Lokeh/thump/ https://github.com/Lokeh/thump/

filoeleven 7y ago

I have a tangential question for you about helix. You switched from hiccup-style lists in hx to functions in helix.dom. I was just looking at fulcro and they made a similar choice. What drove that decision for you? One of the things that first drew me to check out reagent and hx was that the components are declared as data. I haven’t tried any of these libs out yet, so while hiccup syntax looks to me to be more idiomatic clojure, there must be solid, practical reasons for implementing them as functions that I haven’t understood yet, and I’m curious to hear more about what they are.

lilactown 7y ago
Performance, primarily. Hiccup that is generated _at runtime_ is incredibly wasteful; you allocate a bunch of immutable vectors and maps, then parse them into React elements and throw them away, every time your component is rendered. This is a constant performance tax on your application and makes Reacts tradeoffs re: virtual DOM worse. React Elements are already data (they are POJOs), so you lose nothing in terms of declarative-ness using hiccup vs. functions/macros. If you're very attracted to hiccup syntax, you can still use hx's hiccup parser with helix (docs incoming) or try out a library I wrote called thump[0], which uses reader tags to parse the hiccup at compile time into React Elements. 0: https://github.com/Lokeh/thump/ https://github.com/Lokeh/thump/