This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-10-30
Channels
- # announcements (15)
- # beginners (99)
- # boot (15)
- # cider (105)
- # cljdoc (2)
- # cljs-dev (17)
- # clojure (132)
- # clojure-conj (1)
- # clojure-dev (5)
- # clojure-italy (19)
- # clojure-losangeles (2)
- # clojure-nl (20)
- # clojure-spec (70)
- # clojure-uk (50)
- # clojurescript (153)
- # core-logic (9)
- # cryogen (4)
- # cursive (6)
- # datomic (40)
- # duct (5)
- # figwheel-main (10)
- # fulcro (245)
- # hoplon (1)
- # jobs (3)
- # leiningen (12)
- # mount (8)
- # nrepl (11)
- # off-topic (1)
- # pathom (16)
- # pedestal (3)
- # planck (17)
- # re-frame (3)
- # reitit (8)
- # shadow-cljs (64)
- # spacemacs (3)
- # specter (20)
- # tools-deps (21)
@ingesol, thanks for the response! The main stumbling block towards using interceptors for this use case was that the fn had to run once after all handled events, but before subscriptions/reactions synced. So: re-frame handles events
-> (some-fn)
-> render/sync
-> re-frame handles events
-> (some-fn)
-> render/sync
... etc. Somehow the interceptor would have to be the last one processed in the handled event queue and I wasn't sure how to guarantee that. Maybe there was a way to do it in the end, with interceptors, or next-tick
, but it felt like fighting against the framework. Taking a step back, I was luckily able to refactor the larger algorithm that this was a part of to avoid the pattern all-together.