Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2020-08-27

Channels

#re-frame
<
2020-08-27
>
mikethompson00:08:45

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

3
Oliver George00:08:04

@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 George00:08:43

That is to say these are kinda equivilent... 

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

Oliver George00:08:48

and 

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

Oliver George00:08:13

(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 George00:08:41

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

Oliver George00:08:59

Bit left field but thought it was worth sharing.

mikethompson10:08:19

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

Oliver George21:08:28

Yep makes sense

mikethompson10:08:34

--------- New re-frame feature incoming. Speak now or forever hold your peace https://github.com/day8/re-frame/issues/639#issuecomment-680500053

👍 3
danielstockton11:08:28

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

danielstockton11:08:47

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

3
Oliver George21:08:17

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]}}))
vs 
(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.