Closed sirmspencer closed 1 year ago
There's nothing wrong with the idea, but I won't implement it. Closing.
Why?
reg-event-fx
BTW, here's what I mean by an interceptor that does the job (untested):
(def wrap-effects
(re-frame.core/->interceptor
:id :wrap-effects
:after (fn [context]
(assoc context :effects {:fx (:effects context)})))) ;; <-- wrap existing effects in a map like this {:fx <existing>}
Then, write your own version of reg-effects-fx
to install this wrap-effects
interceptor immediately before the event handler is called (my code below is based on existing code for reg-effects-fx
here)
(defn reg-event-fx2 ;; <-- my new name
([id handler]
(reg-event-fx id nil handler))
([id interceptors handler] ;; vvvvvvvvvvvvv
(events/register id [cofx/inject-db fx/do-fx std-interceptors/inject-global-interceptors interceptors wrap-effects (fx-handler->interceptor handler)])))
;; ^^^^^^^^^^^^^
(also untested)
Notice the use/placement of wrap-effects
That's neat, I will try that.
"I regret putting the syntax sugar for subscriptions into re-frame core". I just saw that expansion of syntactic sugar in 1.3 and thought this idea was in line with that. It's interesting to hear you already regret that change.
What do you suggest?
Since any effect in the returned map for reg-event-fx can be added to the :fx effect, could you consider overloading reg-event-fx to take just the :fx vector as a response?
Can be written as
So an overloaded reg-event-fx could accept this as a response, and assume :fx.