Fork me on GitHub

New explanation of dominoes 1,2,3

👍 1

It is very clear Mike, Just may be one confusion for me that might need clarifying. I understant how functions are associated with :db and :GET that are defined in the event handler. But may be it might be interesting to show how this logic is similar/different with a :dispatch key used to dispatch a new event

Marlus Araujo15:06:58

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


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


So I'm a little pesemistic about getting that idea across via an infographic


This new one continues the idea of noting (in small text, granted) that the queue is FIFO


Mmm, yeah, I see.


I thought the first message from @U2FRKM4TW 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.


@U071CG4QY 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.


@U2FRKM4TW 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.


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 suggests that with layer 3 subscriptions, components will re-render less but it’s not entirely clear why.


@gekkostate I'm wondering if you have seen this page:


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.


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.


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.