Fork me on GitHub
#re-frame
<
2017-08-06
>
jebberjeb16:08:50

@mikethompson that's a useful doc, thank you

jfntn16:08:28

@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

mikethompson23:08:29

@jfntn Yes, I've certainly considered it. What usecase makes you interested in this feature?

mikethompson23:08:42

Would you need for example the ability to add and remove "global" interceptors dynamically?

mikethompson23:08:16

Or would it be one or two interceptors, nominated upfront, and then used forever more.

jfntn23:08:41

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

mikethompson23:08:44

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.

jfntn23:08:58

Ah interesting i thought this would be implemented at the handler level

mikethompson23:08:42

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?

jfntn23:08:21

Uses cases for me are numerous, one obvious example would be an fx that needs some bit of state

mikethompson23:08:27

Before you know it, you've build an entire castle of abstraction

mikethompson23:08:54

Can you expand on that usecase?

jfntn23:08:22

Say an fx that needs an auth token from the db

jfntn23:08:43

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

mikethompson23:08:18

So how many of your event handlers actually produce this kind of effect?

mikethompson23:08:55

I'm guessing it is large percentage if you want a global interceptor

mikethompson23:08:00

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)

mikethompson23:08:52

Interceptors can be effectful, if you need them to be

mikethompson23:08:59

(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))

mikethompson23:08:25

Of course, you'd still need a way to inject this "global interceptor"