Just shipped some nice updates to cljdoc that were partly inspired by re-frame.interop being very different depending on platform: https://cljdoc.xyz/d/re-frame/re-frame/0.10.5/api/re-frame.interop (platform specific source links, docstrings, arglists) 🙂

Hi. I want to write an interceptor that blocks handlers from executing under certain conditions. What I am thinking to do is replacing the handler in queue with identity. Is this the right way to do it ?

Would it be better to have a no-op branch in the handler? I can see it being difficult to debug something like that occurring at the interceptor layer

It would be indeed better but i am refactoring an old middleware

I would have to refactor ALL the handlers

with no-op

@hee-foo It's not possible with an interceptor, but you can write your own versions of reg-event-{db,fx,ctx} that wrap the handler with something that conditionally runs the initial handler.

@p-himik so the idea of replacing last item in que ue is not going to work ?

I though last item was the handler

@hee-foo You mean the vector of interceptors stored in re-frame.registrar/kind->id->handler? If so, you can even remove it completely, but you have to be careful: remove it only once, right after all event handlers have been registered, and before any events have been handled.

i am not aware of re-frame.registrar/kind->id->handler, i will check it right away

I was refering to :queue

in context

Oh, huh. I completely missed that.

the idea was to intercept :before replace last interceptor in :queue from context wiht identity , since the last

interceptor is the handler, correct?

Again - you can just remove it, no need for identity. Each handler function is wrapped in an interceptor.

Didnt think of that

thanks @p-himik

This simplifies thinks a bit. I will just remove it

🙂

@hee-foo Probably something like this, although I did not test it:

(def do-not-handle-iterceptor
  (rf/->interceptor
    :id :do-not-handle
    :before (fn [ctx]
              (update ctx :queue (comp pop vector)))))

@hee-foo Ah, that won't work - re-frame converts the collection of interceptors into a queue, so you'll have to re-create that.

yes i know

i had already a function

@p-himik

(defn- block-handler [queue]
  (as-> queue $
    (reduce conj! (transient []) $)
    (pop! $)
    (conj! $ identity)
    (reduce conj #queue [] $)))

of-course its a little simplier than that since i dont need to insert identity

Also, maybe making it transient actually takes more time since usually the number of interceptors is rather small. If you care, you should measure that.

not sure if i get that

the transient collection is an intermediate collection

transient access is more time consuming than regular rbb vectors ?

I thought transients were rbb vectors

Maybe, I have no idea to be honest - never got that deep into CL[JS]. But I've had situations where removing transient/`persistent!` resulted in increased performance.

Also, you probably meant rrb vectors?

yes

😛

hm

into uses transients

so i should use into anyway

anyway thanks

(->> queue
    (into [])
    (pop)
    (into #queue [])))

something like that could work

@hee-foo That creates two collections, but you could create one. into accepts transducers, and take creates a transducer.

indeed

(into #queue [] (take (- (count queue) 1)) queue)

(dec (count queue))

Ah, right. 🙂

🙂

Python-based cognitive bias.

i was goint to ask if you write to much imperative code

😛

Looking at it right now. It tries to look back.

sorry i dont understand

you are refering to the interceptor chain ?

No, it's about the imperative Python code. A heavily paraphrased "And if you gaze long into an abyss, the abyss also gazes into you."

Ha

😄

have you tried hy ?

Nope, and don't really want to, to be honest.

@martinklepsch the re-frame docs on cljdoc are very readable now, nicely done!