Idle thought of the day. I think re-frame handlers would be more composable if they returned two keys :db and :fx where :fx is a collection.

:db needs to be threaded through as each handler modifies the app-db in turn

:fx would allow all side effects to be kept in a list and executed in turn. No chance of clobbering each other.

e.g {:fx [{:dispatch ...}{:dispatch ...}{:dispatch ...}{:dispatch ...}]

So to compose you thread :db through handlers and collect up all :fxs returned.

Expecting answers such as: been there done that, you're a monster, shouldn't you use more interceptors...

@olivergeorge It is a good idle thought. I have made this comment elsewhere: if I had my time over again, I would absolutely make effects be a seq, rather than a map

Upside: 1. It gives ordering (not that useful, but an interesting property) 2. no need for dispatch-n as you point out (this same -n issues comes up a lot with other effects like http GETs etc Downside: 1. slightly nosier visually with the additional structural nesting. 2. breaking change

So I'm interested in your idea because it is a way to take away Downside 2, maybe.

@olivergeorge ^^

In terms of ordering, if I return both effects {:db ... :fx [....]} which effect is actioned first? :db ?

What if we put dB inside fx?

I think :db is a special case. it's changing state... not triggering side effects. In fact, it's important to keep it out if you want to compose a bunch of simple handlers together which I think would be really nice and avoid a lot of typical boilerplate in handlers.

There can be only one

I guess there are cases where multiple fx would conflict (excepting :db) but none come to mind.

I suspect it doesn't matter if :fx or :db is actioned first since they are independent... fx never have access to current app-db state.

So long as all fx are triggered and the :db is updated before any other events are processed then it's fine. (In reflection, I'd do the :db first to allow for :fx which act on the app-db atom directly. Not something to encourage but logically what you'd expect - state has changed and after effects play out)

I suspect the {:db ... :fx []} can be handled by re-frame v1 via an interceptor. Sounds fiddly but can't see why it wouldn't work.

Could even be a new type of event handler registration which handles the return value differently: re-frame.core/reg-event-fsm (or whatever)

(so non-breaking addition to reframe)

@olivergeorge https://github.com/day8/re-frame/issues/639

probable noob question, but why is it that when i dereference a subscription inline like so

(let [my-data @(re-frame/subscribe [:my-sub])]
  (fn [] 
    [:div my-data]))

(let [my-data (re-frame/subscribe [:my-sub])]
  (fn [] 
    [:div @my-data]))

Thanks @mikethompson I'll look forward to seeing what others think about it. I've done my best to clarify my thoughts in a comment.