This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-05-31
Channels
- # aws (2)
- # beginners (101)
- # cider (8)
- # clara (8)
- # cljs-dev (3)
- # cljsrn (17)
- # clojars (2)
- # clojure (67)
- # clojure-austin (2)
- # clojure-finland (1)
- # clojure-france (5)
- # clojure-italy (3)
- # clojure-nl (3)
- # clojure-russia (2)
- # clojure-serbia (1)
- # clojure-spec (72)
- # clojure-uk (112)
- # clojurescript (92)
- # core-async (74)
- # core-typed (2)
- # cursive (8)
- # datomic (2)
- # duct (5)
- # emacs (35)
- # events (11)
- # fulcro (32)
- # instaparse (9)
- # jobs (1)
- # luminus (1)
- # lumo (3)
- # off-topic (118)
- # om (2)
- # onyx (10)
- # pedestal (5)
- # re-frame (21)
- # reagent (48)
- # reitit (40)
- # ring (12)
- # shadow-cljs (113)
- # spacemacs (21)
- # tools-deps (47)
I am looking for a way the perform a side effect when I value in the app-db changes, is there a good pattern for that? a little bit like a watcher on a regular clojure atom
I used track
function for this purpose: https://reagent-project.github.io/news/news060-alpha.html
thanks, that looks useful. It doesn’t seem to work with re-frame subscribe reactions, do I have to use it with the global app-state ratom?
@mikerod thanks. I specific one. I looked at interceptors before but I was still learning and I could not work out how it might be useful.
Would the idea be to say convert the reg-event-db
that updates that value in the db to a reg-event-fx
and then have an interceptor that added an effect to the :effects
key within the context using an :after
function?
@sofra I don’t think I know the situation well enough. If you want to do an effect that specifically just goes with a reg-event-db
event handler, then you’d just use a reg-event-fx
for that specific handler that returns an effects map with both the :db
effect (e.g. updating the db) and whatever other effects you wish to perform.
You can add your own effects via the reg-fx
handlers.
@mikerod yes, but the documentation says that the effects can happen in any order, I was looking for a way for the side effect to happen only after the db had been updated
the only thing I have found that may do it is https://github.com/Day8/re-frame-async-flow-fx
The intercepter pattern would be for a less-localized situation, where perhaps you have multiple event handlers that may end up changing the part of the db
you are interested in. In that case, I think the idea would be to have an :after
intercepter that noticed these changes and then added it’s own :effects
then.
well, the :after
intercepter would see the :db
change via the [:effects :db]
of the context
. It wouldn’t have “happened” yet, but does that strictly matter?
What I mean is, you could see what is going to happen to the db and then add your effect
@sofra but perhaps your case does require something more involved. I haven’t used re-frame-async-flow-fx
. It does look like it may be relevant to you though.
There are a few intercepters built-in to re-frame
too in case you didn’t notice them here
https://github.com/Day8/re-frame/blob/master/docs/Interceptors.md#appendix