Fork me on GitHub
#re-frame
<
2022-03-17
>
Kimo14:03:53

Is there any rule against adding effects in an interceptor's :before handler? By the time :after runs, I don't see the effect there.

p-himik14:03:41

reg-event-db adds effect :db to the :effects map in the context. reg-event-fx replaces the whole :effects map in the context - perhaps you're seeing this. reg-event-ctx replace the whole context - so could also be this.

Kimo15:03:55

I see, thanks. That seems to rule out my use case. Hoping to design an interceptor that loads data from a cache (coeffect) if available, and dispatches a request (effect) if it's not. I'm just not sure how to use a such a predicate from :before in the :after handler.

p-himik15:03:25

Given how the aforementioned event registering functions work, you can't do it reliably in a :before interceptor because your effects might get overwritten. But why do you need :before? Why not just use :after for everything?

Kimo15:03:26

I was thinking the effect might need the data as a coeffect if it was available. Maybe not, though.

p-himik15:03:46

Coeffects don't disappear after the event handler is run. Unless you used reg-event-ctx, which, as I mentioned, can replace the whole context along with the coeffects. But same is true for any other interceptor - e.g. you can't really use path with reg-event-ctx if you replace the whole context in the latter. So if you don't use reg-event-ctx or update the context and not just replace it, all should be good.