Fork me on GitHub
#hyperfiddle
<
2023-09-26
>
joshcho01:09:10

Curious what people think of Svelte from the perspective of Electric

joshcho01:09:49

from a cursory look, runes (new in svelte 5) feel like incidental complexity/artifacts

Hendrik05:09:39

Given how electric manages updates. Are there already best practices how to manage purely frontend state with electric? I can think of 3 alternatives. 1. one global atom. Having an e/watch in any clientside component. pro: simple to implement, con: triggers some reevaluating in every component on state change 2. split state into many atoms. Pro: absolute minimum recalcultion on state changes. Con: clutters state 3. fulcro like global atom. state is injected as fn arg into component. Pro: good reasoning about state. con: “props drilling react like problems” Personally, I would go with method 1. How would you do it with electric?

Hendrik06:09:36

I just realized that I can do another 4th alternative.

(def !state (atom {}))
(e/def state (e/watch !state))
(e/def topic1 (:topic1 state)) 
(e/def topic2 (:topic1 state))

(e/defn MyComponent []
(dom/div (dom/text topic2)))
This has the benefit of having state in 1 place. No props drilling is needed in the component. Nested components are decoupled. State could be even a normalized db like in fulcro with denormalization for components. This 4th alternative seems the right way to go

xificurC07:09:32

all of the above work. I'd probably store it in datascript

nivekuil07:09:59

I wrote my own, first with odoyle+asami for reactive inline datalog, now in an EQL style heavily inspired by fulcro. it works well though I need to rewrite it yet again on top of differential electric soon. Note that your option 4. is basically how react renders but even less efficient since you don't get to skip subtree diffs

👏 1
nivekuil07:09:15

also, don't underestimate the importance of transactions. i've ran into some very confusing stacktraces in electric already because of badly timed state updates

👀 1
xificurC07:09:26

> since you don't get to skip subtree diffs What do you mean by skipping subtree diffs? In option 4 (dom/text topic2) will re-run only if topic2 changes. If the !state atom updates but (:topic2 state) returns the same value (same via clojure.core/=) downstream dependencies will skip all work

nivekuil07:09:07

it needs to run every diff (checking if (:topicN state) returns the same value) every time !state updates since he doesn't want to do prop drilling

nivekuil07:09:19

with react you diff mounted components, and if the parent doesn't render no work is done for its children

nivekuil07:09:44

basically you want to diff as far upstream as possible. that's why react's low level built-in diffing (vdom<->dom) isn't that impressive

👍 2
xificurC08:09:13

checking if (:topic2 state) is = when there have been no changes on that branch succeeds at pointer comparison, I wouldn't worry about that cost

xificurC08:09:55

in our ideal world view diffing is accidental complexity introduced at the edges of your system where you have to interoperate with third parties that send you collections. e/for diffs and in next electric version everything will be differential

nivekuil08:09:19

it is very cheap and react (in the happy path) is plenty fast, though not quite free, so you do get something of a "death by a thousand cuts" effect. definitely not relevant for most apps

xificurC08:09:24

e.g. if rama can send fine grained updates (CUD) we should be able to integrate that seamlessly and achieve "perfect" performance

nivekuil08:09:04

diffing as a threshold problem makes sense, it's like a breakdown of trust/communication so you have to verify first which has a cost

Dustin Getz10:09:42

to address the q of state management: I hesitate to prescribe solutions here yet, we are still learning - electric is different, and differential electric (coming this year) is even more different and extremely powerful

Dustin Getz10:09:51

UI5, the optimistic update forms library, has a new flow-based pure functional state management approach (no callbacks). it is blocked on differential electric

Dustin Getz10:09:37

my instinct is that callback-free flow composition is the path forward for electric state management but in the meantime we are stuck with change callbacks

Dustin Getz10:09:32

also since the UI5 workstream is blocked, this is all just a hypothesis until we see it working

siddharth yadav18:09:09

Is it possible to do e/server or e/client from a react or reagent component? I am trying to make a svg playground UI which has codemirror, prosemirror and a few other type of nodes in the playground. I currently have this in working state using re-frame and reagent but I want to move over to electric.

Dustin Getz18:09:47

no, those special forms are only valid inside the electric macro contexts

Dustin Getz18:09:55

the best you can do is use electric to pre-fetch the data and pass it into the foreign context

Dustin Getz18:09:50

or implement some sort of subscription machinery form the foreign context to send an event back into the electric context to signal a request for more data

siddharth yadav18:09:56

oh ok thanks for the quick reply Dustin. I really like working with electric, I find it much more intuitive to use than reagent and any other framework. I think I should implement the svg playground in electric itself not sure the complexity of doing so.

Dustin Getz18:09:56

can i see a screenshot of what you have?

siddharth yadav18:09:15

This is screenshot I have from the working code in reagent, the blue part is codemirror editor when we run the code we get output in the white area. We can then pass this result to another such node. The playground in which these nodes exists is build on reactflow. Sorry I could not share a better screenshot because I don't have a running build as of now.

👀 2
xificurC07:09:27

bridging react is a common question, here are some links • https://github.com/hyperfiddle/electric/blob/c910935c7068ee5af457a64157a6e12923b8393e/src-docs/user/demo_reagent_interop.cljchttps://github.com/KevinTung/electric-testing-1/blob/main/src/app/todo_list.cljc (@U03RQQ2L8LE’s repo, I helped) There are rough edges we can help clean up. If you hit a specific scenario where you get stuck I'll be glad to help

siddharth yadav08:09:39

Thanks @U09FL65DK and @U03RQQ2L8LE! I will try to use this and ask if I hit some blocker.

🙌 1
wei20:09:42

btw if anyone is interested in wrapping React Flow or porting it to Electric, I'd be interested as a consumer and/or contributor. it's a great fit for Electric!

👀 1