hyperfiddle 2024-02-14 | Slack Archive

Is differential electric already out there in some form to play with?

not yet

👍 1

In (e/for-by f [x xs] (dom/li ,,,)), I'm unsure of what f does, and hence why e/for-by identity leads to excessive recomputation. My guess is that for-by gives each child (dom/li in this case) an invisible ID that is equal to f(x), so the dom node (or whatever) can be re-used when x changes, so f = identity would entirely replace our dom/li when any aspect of x changes, instead of re-using the existing node (/child). Am I close? Why doesn't e/for-by (constantly nil) break?

Dustin Getz16:02:17

yes, if you have used reagent or reactjs this is the “key”

Dustin Getz16:02:26

https://stackoverflow.com/questions/28329382/understanding-unique-keys-for-array-children-in-react-js/43892905#43892905

Dustin Getz16:02:54

as described here : https://electric.hyperfiddle.net/(electric-tutorial.demo-system-properties!%53ystem%50roperties)/

Tommy Jolly16:02:01

Yeah i'm afraid i've not used React. I did re-read the System Properties readme, but didn't quite follow enough.

Tommy Jolly16:02:18

One confusing thing in that readme is calling it a "reactive map operator" implied to me that it e/for-by f [x xs] binds x like e/for-by identity [x (map f xs)] , which I now know isn't true, but threw me.

👀 1

Tommy Jolly16:02:59

Either way I get it now 🙂 Looks like a good default is to iterate over a vector of maps, and use e/for-by :db/id to do so.

👍 1

Tommy Jolly16:02:48

Thanks!

Tommy Jolly16:02:54

Oh! Final Q. In Electric, presumably this "key" is on the implicit do that forms the for-by's body?

Dustin Getz17:02:22

Yeah, the for-by body is wrapped into an e/fn, and the lifetime of that e/fn is controlled based on that key

2024-02-14

Channels