Fork me on GitHub
#reagent
<
2021-03-12
>
jeaye17:03:29

I've used reagent a ton, but never any vanilla JS + React. I'm curious, does vanilla JS + React allow components to be so easily made from pure data transformations? Simple example being code like (into [table] (map (fn [r] [row r]) @rows) , but this also carries over to transforming existing hiccup forms by way of conj or similar.

p-himik17:03:11

<table> in JSX will result in a call to React.createElement(...). A resulting React element is an immutable data structure. All you can do to it afterwards is to call React.cloneElement(...) and override some properties and children. So, you cannot simply (conj [table ...] new-child), but you should be able to achieve the same result.

jeaye17:03:27

Right, anything you can do in reagent, you can do with React in JS. What you're alluding to is exactly my core inquiry, though: how painful is it?

p-himik17:03:28

No idea, I've actually never used JSX myself. :)

jeaye17:03:35

I'm trying to make the case to some folks for using CLJS + Reagent over JS + React, which is why I ask.

p-himik17:03:56

If those folks never use cloneElement, then it would be harder to make such a case.

p-himik17:03:19

FWIW, I think it would be much easier and also more productive to make a case of CLJS vs JS, and then show that Reagent experience is also at the very least comparable to React.

lilactown21:03:48

IME working on large applications, manipulating children as data is a code smell to me. it usually couples the parent and children in ways that make it very difficult to untangle

lilactown21:03:36

if I was selling CLJS + Reagent, I would focus on the ease of using immutable data and the rich standard library via clojure.core, and the reactive MobX-like paradigm that reagent's ratom/reactions provide

jeaye19:03:18

Yep, I focused on all of the data we needed to transform in order to build the UIs, along with how the shape of that data is highly ambiguous. Ended up with an approval.