Clojurians Log v2
re-frame
New explanation of dominoes 1,2,3
Newbie question: how is the best way to dispatch events that has no db side-effects? To return db is always required?
(reg-event-db
:test-signal
(fn [db _]
(js/console.log "signal was tested!")
db))
What am I not explaining well? What is confusing? What needs more clarification or more detail or less detail?
This is a question particularly for those currently learning re-frame, but please jump in with any thoughts if you can still remember what it was like to be new
@jahson If you have effects like e.g. :db and :dispatch in the result of a single event handler, you cannot know what effect handler will be called first - for :db or for :dispatch.
But the changes in the DB will be there before the event handler for the event mentioned in :dispatch is called. Because the effect handler for :dispatch doesn't do anything but put the event on the FIFO queue.
Since the queue is FIFO, as mentioned in the infographic, the event will be scheduled to run last as compared to other events that are already there.
@p-himik Thanks for clarification. I know about effects and FIFO queue, I was talking about seeing people being confused.
And if you have your own effect handler, you cannot rely on app-db being updated before that effect handler. IIRC this is even mentioned somewhere in docs.
There have been a few questions on the ordering of :dispatch, :db, and other effects. I know that the information is there on the diagram, but maybe it's not immediately obvious.
Do you think it could be emphasized somehow? Or maybe an additional diagram (or text with [pseudo]code blocks) would be more appropriate.
The existing infographic, which I am partially replacing, seems to make the point about a queue clear but .... it has never stopped the questions https://day8.github.io/re-frame/event-handling-infographic/
So I'm a little pesemistic about getting that idea across via an infographic
This is not quite related to the new explanation but it would be great if there was an additional explanation for “layer 3” subscriptions. Are “layer 3" subscriptions, beneficial only for doing additional computation? Or is it also that, by adding layer 3 subscriptions, we render less? Eric Normand in his https://purelyfunctional.tv/guide/re-frame-building-blocks/#subscriptions suggests that with layer 3 subscriptions, components will re-render less but it’s not entirely clear why.
This new one continues the idea of noting (in small text, granted) that the queue is FIFO
@gekkostate I'm wondering if you have seen this page:
I added it in the last 6 weeks or so
Perhaps it is a bit hidden in the "intermediate section"?
And, to answer you question, layer 3 are not about less rendering (in general). The propagation pruning layer is Layer 2. Layer 3 is about performing the the expensive computation.
Now, in theory, it is possible for an expensive computation to be the same as "last time" and, as a result, for there be no further propogation to the views, but that's kinda unusual in practice.
Yes! So I really like this page. The infographic is super helpful. I like that there’s a section especially for “Why Layer 2” because it makes the relationship between layer 2 and the layers very clear.
Right! That makes sense. I read the explanation that in the subscriptions doc and then contrasted it with Eric’s and was a tad confused. I think it would be helpful to have what’ve you just said in the docs.
Mmm, yeah, I see.
I thought expensive computation should have been done in events haha
Thanks.
How does it reconcile with this page then? http://day8.github.io/re-frame/Solve-the-CPU-hog-problem/
That page is about cases where you have to do lots of CPU intensive calculations in an event handler, which will tie up the execution thread for too long. It is about how you periodically hand back control to the browser. I'm not sure it is related to the question of what should happen in events and what should be done in subscriptions
Well, I thought it was recommending to put heavy computing in event handlers?
So it recommends to not do them in subscriptions? I am sorry if it seems confusing.
I think it depends on what you mean by "heavy computing". Something that locks up the thread for many seconds and stops redraws should be done in an event handler, yes, and not in a subscription. And that page show you how to chunk that computation down to time into smaller slices.
Thanks!
I thought the first message from @p-himik was about non-guaranteed order of effect processing, but I'm confused now.
I've also seen people being confused about :dispatch and :dispatch-n effects. Like, where these new events would appear? After their "source" event or after the last event in queue?
There's also dominos / dominoes in this picture.
I think the rationale for doing it in the subscription is that you will only need to calculate when you need it. So, we’re essentially delaying calculation until necessary. Otherwise, we’re calculating without use.