Fork me on GitHub

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.


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.


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.


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?


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


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.