This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-09-25
Channels
- # announcements (2)
- # babashka (22)
- # beginners (31)
- # calva (4)
- # cider (26)
- # clj-kondo (10)
- # clojure (32)
- # clojure-europe (1)
- # clojure-italy (3)
- # clojure-nl (3)
- # clojure-spec (16)
- # clojure-switzerland (5)
- # clojure-uk (25)
- # clojurescript (108)
- # clojutre (15)
- # code-reviews (3)
- # data-science (1)
- # datomic (92)
- # emacs (1)
- # fulcro (8)
- # graalvm (8)
- # jackdaw (8)
- # jobs (1)
- # jobs-discuss (1)
- # leiningen (6)
- # off-topic (56)
- # pathom (6)
- # pedestal (5)
- # re-frame (11)
- # remote-jobs (1)
- # shadow-cljs (4)
- # spacemacs (2)
- # sql (41)
- # tools-deps (7)
- # xtdb (25)
An global interceptor?
See FAQ on how to set one up
cool, yep used a global interceptor thanks!!
@danieleneal the other way you can do it, which is not quite as good IMO, but I'll include it for completeness is ...
to create your own version of dispatch
. Let's call it emit
And then you make email
log whereever it needs to about what event is being queued, before then actually calling dispatch
The problem with this method can be (in some cases) that lots of events are dispatched in a hurry, and although you are log them all ... later on you are not sure which one you are currently processing. Generally speaking this method can work reasonably. You emit an event and then handle it. Then you emit another one, then handle it, etc. There's only ever one event at a time.
BTW, the other problems with the emit approach is that you then have to use an effect handler :emit
rather than :dispatch
. Which means yo uhave to write that effect handler too.
So, yeah, not as good. But mentioned for completeness
Since we use re-frame we live in the future already, but here's a nice article I found about changing states. (also dips into api states, etc.) https://josephg.com/blog/api-for-changes/