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

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))

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

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

@gekkostate Yes, exactly correct. Consider an app which maintains a list of thingos in app-db. And that this list is displayed in one panel, in a sorted way. When that panel is not showing, we don't need the list of thingos sorted. Only when that panel is showing should we go to the computational effort of sorting. In such a case, we'd put the sorting in the subscription. The need for sorting is associated with the existence of a view subscribing to the data in that way. @UEQGQ6XH7 ^^

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!