Fork me on GitHub
#re-frame
<
2018-05-31
>
scknkkrer10:05:18

thanks for the info, @gregg.

sofra14:05:49

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

sofra23:05:38

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?

sofra00:06:17

this worked great thanks, I just got my code wrong. Works with reactions no problem.

mikerod14:05:59

@sofra when any value changes in the db or specific ones?

mikerod14:05:09

However, either way, I think that you may want to look at intercepters

mikerod14:05:13

Sounds like it may be of interest

sofra14:05:21

@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?

mikerod14:05:03

@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.

sofra14:05:15

@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

sofra14:05:21

the only thing I have found that may do it is https://github.com/Day8/re-frame-async-flow-fx

mikerod14:05:02

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.

mikerod14:05:46

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?

mikerod14:05:15

What I mean is, you could see what is going to happen to the db and then add your effect

mikerod14:05:29

Or perhaps do something like :dispatch-later, don’t know

mikerod14:05:07

@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.

mikerod14:05:21

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

sofra23:05:17

@mikerod thanks for the help, I will play with it a bit today

4