This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-10-30
Channels
- # aleph (4)
- # announcements (5)
- # architecture (1)
- # aws (5)
- # babashka (12)
- # beginners (143)
- # chlorine-clover (4)
- # cider (16)
- # clj-kondo (44)
- # cljfx (26)
- # cljsrn (2)
- # clojure (34)
- # clojure-europe (28)
- # clojure-gamedev (1)
- # clojure-nl (3)
- # clojure-provo (2)
- # clojure-spec (6)
- # clojure-uk (17)
- # clojurescript (99)
- # code-reviews (6)
- # core-async (15)
- # cryogen (9)
- # cursive (14)
- # data-science (1)
- # datomic (16)
- # duct (1)
- # events (4)
- # exercism (1)
- # figwheel-main (3)
- # fulcro (3)
- # hugsql (7)
- # leiningen (4)
- # malli (15)
- # off-topic (13)
- # pathom (8)
- # re-frame (7)
- # reitit (35)
- # remote-jobs (1)
- # sci (10)
- # shadow-cljs (32)
- # sql (5)
- # tools-deps (102)
- # tree-sitter (3)
- # uncomplicate (7)
- # vim (40)
- # xtdb (8)
Wondering if there's a common pattern for an interceptor which stops a handler from being called
Looks like you could empty the :queue from the context... something like that perhaps.
@olivergeorge I've never used the technique. But certainly possible as you say.
An idea - when -deref
is called on a sub somewhere where reagent.ratom/reactive?
is false, it should issue a descriptive warning, maybe with a link to the relevant documentation entry.
What do you think?
(I'm assuming my understanding of what reagent.ratom/reactive?
checks for is correct)
+1, to ensure the deref of a subscription is always inside a reagent component. There should also be a way to opt out of that.
Find re-frame events and subscriptions easily => https://github.com/borkdude/grasp#finding-keywords