known issue, search for many discussions explaining what’s happening, use e/snapshot to work around. next version of electric-ui is callback free

thanks! I've managed to work around it with e/snapshot like this:

(e/defn Page
  []
  (e/server
   (let [!state (atom 0)
         state  (e/watch !state)]
     (e/client
      (ui/button
       (e/fn []
         (let [state (e/snapshot state)]
           (println "client CLICK " state)
           (e/server
            (println "server CLICK " state)
            (swap! !state inc))))
       (dom/text "button"))))))

note that the transaction here (swap!) does not depend on state, the thing causing the cycles are the printlns. if you remove the printlns you don’t need snapshot

you need to understand this to use ui4 unfortunately, ui4 is robust to latency and concurrency but only if you understand the rules

ui5 will be easier

As of now this is all in prototype stage, I am building for future where I would have millions of these nodes and even if I would be seeing some very small subset of them they could change because another agent changed some other part of the graph and maybe that changes some part of my view

please post code (i mostly read this on mobile so please post in a mobile friendly way, use the file attachment feature for longer snippets)

Here I attached the whole code part of it is some logic to convert b/w different coordinate systems and calculating position on canvas when circle is moved. view, circle and line function are the ones that would be directly related to the problem

I was not using it previously, but since you mentioned I re-read my code, docs and some chat. I was using e/for-by under client but the values are on server so I fixed it and now using value from the server like so (14 loc)

Now the UI is lagging more I think due to the nested for-by.

I'll be using this as a way of exploring the idiomatic electric way to do data visualisations.

you can capture a ref to dom/node like this: (let [el (dom/svg ... dom/node)] ...) the key is that the dom syntax macros return the final child

you can also move the .beginElement effects into the body of svg/animate where dom/node is available, giving you a dependency on it

in your case i think that is sufficient?

for harder use cases if establishing a causal dep in the DAG is too difficult you can use the MutationObserver API, at least until we have time to take a look at making this better

Cool. The returning dom/node into a let binding is a good trick. It’s needed to actually get the length of a line because calling it inside that is not available. I still haven’t quite landed on animating after everything is loaded. By the time the visualisation renders its like 1/3 of the way through the animation. I’ll keep playing with it 🙂

Looking more at mutation observer I might need that.

Solved this using Web Animations API and capturing dom/nodes

I use nano-id

core has (random-uuid)

hopefully none or minor changes to current APIs, maybe some additions

why do you ask

Mainly just curious

Wondering if it was a more implementation change than anything else