@fmnoise Yes, that's currently the only way to inject a subscription. The alternative is to actually compute the value, when any inputs to it change (which is what a subscription does reactively), and have the value you need (the value of the subscription) materialized in app-db. Perhaps using the on-change Interceptor on any event handlers which make changes to the inputs.

Oliver George 2020-08-27T00:46:04.004Z

@mikethompson bit of a random idea related to the whole reg-event-dbfx... the general "composition" idea feels tantilisingly close to allowing multiple handlers on one event

Oliver George 2020-08-27T00:47:43.005400Z

That is to say these are kinda equivilent...

(reg-event-dbfx :event-id interceptors [function1 function2 function3])

Oliver George 2020-08-27T00:47:48.005600Z


(reg-event-dbfx :event-id interceptors function1)
(reg-event-dbfx :event-id interceptors function2)
(reg-event-dbfx :event-id interceptors function3)

Oliver George 2020-08-27T00:50:13.007800Z

(ignoring potential issues relating to "re-registering" at dev time - surmountable by registering vars #'function1 or giving each a unique key like add-watch)

Oliver George 2020-08-27T00:50:41.008400Z

Value of this might be separation of concerns. You decorate events with behaviour rather than putting one function in charge of the lot.

Oliver George 2020-08-27T00:50:59.008700Z

Bit left field but thought it was worth sharing.


@olivergeorge Each time I think about multiple handlers, I start to also think about ordering of them. Not long later, I tend to back away slowly. It has always seemed complicated for not a lot of additional value. So, it is probably the lack of a compelling usecase that has stopped me wanting to introduce the complexity.


--------- New re-frame feature incoming. Speak now or forever hold your peace


Does anyone SSR their re-frame app from aws lambda/nodejs?


Any potential pitfalls? Helpful libraries that take care of lambda handler -> express routing?

Oliver George 2020-08-27T21:26:28.014400Z

Yep makes sense

Oliver George 2020-08-27T21:30:17.018Z

Just a thought. Not directly reg-event-dbfx related. Data literals as handlers could be a handy shortcut for "effects on event" type scenarios. e.g.

(rf/reg-event-fx ::close-db
  (fn [] {:app.fx/close-database {:resolve [::close-db.success]
                                  :reject  [::close-db.error]}}))
(rf/reg-event-fx ::close-db
  {:app.fx/close-database {:resolve [::close-db.success]
                           :reject  [::close-db.error]}})
Logically these are fx only with the possible exception of bootstrapping the :db value. In the absence of easily composable handlers (long live reg-event-dbfx) I have found myself doing a lot of these types of handlers to reuse code (e.g. many events cause specific behaviour). It's one of the motivations which I think makes reg-event-dbfx exciting. Perhaps there's an argument for allowing re-frame handlers to be data literals. I see two possible changes • In reg-event-fx (et. al.), check if the handler is a map and if it is just return the value. • In reg-event-dbfx with a vector of handlers, do the same but wrap any maps you find with (fn [s _] (update s :fx concat (:fx m))) but probably checking for :effect-keys in m first to allow for other effects.