Hello, I hope someone here can clear up my confusion on around when the UI updates in response to updated atoms with relatively slow calculations or sequences of calculations. My understanding was that anything that dereferences an atom would update at that time, but it seems that UI updates are deferred in some way. For example, in code similar to my example (see below), what I would expect to see in the ui, is 1. "ready" would change to "working ..." almost instantly 2. 3 seconds would pass, then result1 would show on the page 3. 3 more seconds and result2 would appear, and "working..." would change to "done" at almost the same time. However, what I actually see is 1. Nothing changes for 6 seconds. 2. "ready" changes to "done" and both results appear. However, I know the atom is actually updating at the expected time because the console.log outputs appear just when I would have expected. So, what am I not understanding here? And how could I get the behavior I was aiming for? BTW, the result is essentially the same if I make result1 and result2 to "reactions" instead of atoms. Thanks for any insight! Eric Code example: (def status (r/atom "ready")) (def result1 (r/atom 0)) (r/atom 0)) (defn slow-calculation1 [] ... takes 3 seconds ...) (defn slow-calculation2 [x] ... takes 3 seconds ...) (defn update-result! [] (reset! status "working ...") (console.log "working ...") (reset! result1 (slow-calculation1)) (console.log @result1) (reset! result2 (slow-calculation2 @result1)) (reset! status "done")) (defn example-component [] [:div [:p @status] [:p @result] [:input {:type "button" :value "calculate" :on-click update-result!}]])

interesting. I don't have an answer for you, but I'm wondering if the results you're seeing occur with even very long times in slow-calculation2? What if slow-calculation takes a minute? Do you still not see result1 until after it is done?

essentially, I'm wondering if the updates are deferred until update-result! is finished or if it's really just the deref's in example-component being delayed

@eric567 if slow-calculation1 is synchronous, then you are blocking the main thread, so reagent never has an opportunity to redraw

if you need to do long running calculations, you’ll need to push them into a webworker if you want the browser to be responsive

easy way to tell is to sequence them using setTimeout, which will yield to the event queue

@trailcapital The longest I've seen in practice is about 10 seconds, and I'm not sure how to make a function that just takes a long time. I'd use Thread sleep in Clojure, but that doesn't seem to work in cljs.

if your calculations are actually cpu-bound calculations, then the answer is definitely that you’re blocking the thread. @trailcapital was wondering whether updates are deferred until update-result! is finished, and the answer is both yes if it is synchronous and no if it is not

@justinlee Thanks! I just tried replacing (reset! result1 (slow-calculation1)) with (js/setTimeout #aide (reset! result1 (slow-calculation1)) 10), and it did sort of what I expected. (That is to say, slow-calculation2 executed in parallel, using 0 as its input, rather than the result of slow-calc1.) So... If I put the sequence of the two slow-calculations in another function and wrap it in setTimeout ... Is that what I'm meant to do? It seems like it would work, but I think you were just proposing a diagnostic experiment. Also, I don't think I really understand. For one thing, although I can see why slow-calculation1 might block the main thread, why doesn't (reset! status "working ...") case a UI update? Is the whole update-result! function blocking the main thread? If I have a long chain of "reactions", will I never see results from earlier calculations before all are completed?

right: the entire update-result! function is blocking the main thread. reagent doesn’t do updates synchronously. it batches updates using requestAnimationFrame (which runs every 16 ms, effectively). so if the main thread is all blocked doing something, then the next RAF will wait until it is done

you can’t have long running calculations unless you yield reasonably often or the UI will freeze up

or if you use webworkers

Thanks for the advice yesterday. I got my on-element drop handler working using reagent.core/create-class, and an atom for the ref.