Fork me on GitHub
Quentin Le Guennec20:10:44

Is a re-frame subscription supposed to see all atom values over time, necessarily? Or can it skip some?


It can skip, if the value was changed multiple times in the same rendering phase.

Quentin Le Guennec20:10:42

I see. That completely explains my issue then. Is there any way to get around this?


To render while you rendering? :) Not really. But you can split updates into multiple operations and use :flush-dom event metadata.

Quentin Le Guennec20:10:54

Okay, I see, I'll look it up, thanks.

Quentin Le Guennec21:10:48

I'm not sure how this is related

Quentin Le Guennec21:10:23

I don't have any intesive work to do, I'm just trying to dispatch-sync a "http request is in progress" marker in the db to avoid a second request to run before the first one has completed

Quentin Le Guennec21:10:55

and as it turns out, dispatch-sync is not enough for that, the db gets updated, the souscription caches don't

Quentin Le Guennec21:10:35

maybe the issue is the 16ms thingy, tho

Quentin Le Guennec21:10:01

yep, flush was what I needed!

Quentin Le Guennec21:10:07

thanks for your help.

đź‘Ť 1

Are you per chance trying to do that dispatch within the event that is sending off the http request?


If so, please just write a function that will update your db with the loading flag to true and have the http request be in an fx vector


{:db (set-loading-flag db) :fx [[:http-xhrio ...]]}


That will be far easier to reason about and is actually atomic without relying on things like flush


I second @U3JH98J4R just set a loading flag to true from the event that dispatches the http request