This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-08-27
Channels
- # admin-announcements (1)
- # announcements (11)
- # babashka (17)
- # beginners (26)
- # calva (6)
- # cider (2)
- # circleci (1)
- # clojure (41)
- # clojure-dev (1)
- # clojure-europe (31)
- # clojure-france (2)
- # clojure-italy (10)
- # clojure-nl (7)
- # clojure-norway (5)
- # clojure-spec (15)
- # clojure-uk (42)
- # clojurescript (4)
- # code-reviews (12)
- # conjure (10)
- # datalog (2)
- # datascript (15)
- # datomic (37)
- # emacs (1)
- # events (5)
- # fulcro (19)
- # jobs (1)
- # jobs-discuss (9)
- # kaocha (2)
- # luminus (14)
- # meander (4)
- # membrane (39)
- # off-topic (26)
- # other-languages (2)
- # re-frame (13)
- # reitit (6)
- # rewrite-clj (39)
- # sci (6)
- # shadow-cljs (33)
- # test-check (15)
- # vrac (17)
- # xtdb (7)
@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.
@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
That is to say these are kinda equivilent...
(reg-event-dbfx :event-id interceptors [function1 function2 function3])
and
(reg-event-dbfx :event-id interceptors function1)
(reg-event-dbfx :event-id interceptors function2)
(reg-event-dbfx :event-id interceptors function3)
(ignoring potential issues relating to "re-registering" at dev time - surmountable by registering vars #'function1 or giving each a unique key like add-watch
)
Value of this might be separation of concerns. You decorate events with behaviour rather than putting one function in charge of the lot.
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.
Yep makes sense
--------- New re-frame feature incoming. Speak now or forever hold your peace https://github.com/day8/re-frame/issues/639#issuecomment-680500053
Does anyone SSR their re-frame app from aws lambda/nodejs?
Any potential pitfalls? Helpful libraries that take care of lambda handler -> express routing?
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.