Rabie 2020-06-28T02:33:35.101100Z

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

Rabie 2020-06-28T02:46:09.103600Z

I was reading the effects doc and I have a question with regard to :

(reg-event-fx              ;; -fx registration, not -db registration
  (fn [cofx [_ a]]        ;; 1st argument is coeffects, instead of db
    {:db       (assoc (:db cofx) :flag  a)
     :dispatch [:do-something-else 3]})) 
Is there a way to dispatch more than one event with the :dispatch key? If not, is it because this use case should never be used and should I use a different logic?


@rnait1977 there is an effect called :`dispatch-n`

Rabie 2020-06-29T01:47:48.118200Z

In that case, is the cofx passed to these :dispatch-n or :dispatch events the same as the original cofx of the reg-event-fx or the one that has been modified by the :db key?


which, can take a seq of vectors to dispatch


@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. @neo2551 ^^




How does it reconcile with this page then?

p-himik 2020-06-28T07:05:35.107100Z

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

p-himik 2020-06-28T07:06:44.107300Z

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.


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.

valerauko 2020-06-28T12:29:20.113Z

is there a list of built-in effect handlers? like the ones that deal with :dispatch and dispatch-n

p-himik 2020-06-28T12:37:05.113100Z

There doesn't seem to be one. There's this section that has to links, but neither of them shows anything useful. But it's pretty easy to search for the usages of reg-fx in the re-frame source code.

valerauko 2020-06-28T12:38:25.113400Z

so i figure this is all then

p-himik 2020-06-28T12:42:57.113700Z

Yep. But there's a number of third-party libraries that add some extra interceptors.


Yeah, in the recent docs upgrade, the list of buildin effect handlers was removed.


I'll fix that


Newly refined infographics on this page ...


I'm interested in comments


@p-himik I added a new panel to stress the FIFO nature of the event queue.


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.


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