This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
@mikethompson that's a useful doc, thank you
@mikethompson thanks but I was aware of that pattern and was thinking something more along the lines of reg-interceptor
and without going into the specifics of how that would work was wondering if it's something you had considered
@jfntn Yes, I've certainly considered it. What usecase makes you interested in this feature?
Would you need for example the ability to add and remove "global" interceptors dynamically?
Or would it be one or two interceptors, nominated upfront, and then used forever more.
Thought about both use cases, 2nd sounds harder to implement and maybe less generally useful, 1st will have a perfect cost of deref'ing the register on every event
BTW, if I was going to support global interceptors, I'd be tempted to do it this way:
1. In reg-event-db
and reg-event-fx
automatically add a single interceptor called say call-global-interceptors
(in the same way that these registration functions already inject two interceptors, make them inject one more)
2. have this call-global-interceptors
interceptor call the currently registered global interceptors ...
3. ... which would have been previously added by a call to say reg-global-interceptor
It is easy for one interceptor call-global-interceptors
to call others.
There's always a bit in this kind of thing once you get into it. Should there be an ordering to the globals? Can you add them and remove them? Can i create an event handler which doesn't have the globals applied?
Uses cases for me are numerous, one obvious example would be an fx that needs some bit of state
Before you know it, you've build an entire castle of abstraction
Can you expand on that usecase?
You can pass that explicitly but it's a lot of boilerplate, global interceptors would allow to remove duplication and capture conventions in a code base in a consistent way
So how many of your event handlers actually produce this kind of effect?
percentage?
I'm guessing it is large percentage if you want a global interceptor
BTW, it sounds to me like you might want: 1. want a global interceptor 2. have that interceptor actually handle the effect itself (it will have access to the effect and the db)
Interceptors can be effectful, if you need them to be
(interceptor->
:id my-effectful-interceptor
:after (fn [context]
(if-let [fx (get-in context [:effects :my-fx])]
(let [auth (get-in context [:effects :db :auth])]
.... do effect
... return context with effect removed because we have already handled it ))
context))
Of course, you'd still need a way to inject this "global interceptor"