Clojurians Log v2

Does anybody else find themselves wanting a :dispatch-many sort of fx? I often want to dispatch multiple effects in response to a single event, and I don't want to couple them all together in a chain.

Something like this:

(defn dispatch-many
  [events]
  (doseq [event events]
    (rf/dispatch event)))

(rf/reg-fx ::dispatch-many dispatch-many)

(rf/reg-event-fx
  ::dispatch-many
  [rf/debug]
  (fn [_ [_ & dispatches]]
    {::dispatch-many dispatches}))

Is this a bad smell, or does everyone do this?

The fx already exists, and it's called :dispatch-n. But combining multiple events into one by wrapping them is definitely a code smell. Move such combinations into a separate event with a specific name.

Cool that it already exists! I'll have to compare implementations. Could you elaborate more on the smell? I often have multiple side effects that I want to trigger, all independent of each other. It seems to me I either dispatch them all in response to the trigger event, or I chain them all together where one calls the next. I'm wary of coupling them in that sort of artificial order.

Here's an example of how I'm using it now: once a user has authenticated, I need to fetch some more stuff and take care of some state management stuff.

(rf/dispatch [::util/dispatch-many
                              (auth/set-auth (:auth-success state))
                              (app.evt/get-capabilities)
                              (app.evt/sync)
                              (form.evt/destroy-form app.const/authentication-form-id)])

> Could you elaborate more on the smell? Re-frame documentation does it much better than I ever could.

> I'm wary of coupling them in that sort of artificial order. Combining them in a new event handler does not couple them in any way.

An intent should be expressed with a single dispatch with a relevant ID and handler. "Dispatch many" is not the intent in your example above. The intent is to finalize the process of user authentication, or something like that.

Ah, I see what you're saying. The event dispatched should be semantically interesting and describable, and you can dispatch as much as you want from inside the event handler.

Also, I went to the docs and found this:

From v1.1.0 onwards, this effect is deprecated in favour of using :fx with multiple :dispatch tuples.

There's a whole bunch of goodies there that are new in 1.1.0, so I'm glad you pointed me there