Fork me on GitHub
#re-frame
<
2018-07-09
>
martinklepsch09:07:09

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

christos14:07:37

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 ?

samueldev14:07:57

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

👍 4
christos14:07:23

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

christos14:07:32

I would have to refactor ALL the handlers

p-himik14:07:50

@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.

christos14:07:56

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

christos14:07:08

I though last item was the handler

p-himik14:07:27

@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.

christos14:07:12

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

christos14:07:18

I was refering to :queue

p-himik14:07:31

Oh, huh. I completely missed that.

christos14:07:32

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

christos14:07:45

interceptor is the handler, correct?

p-himik14:07:53

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

christos14:07:26

Didnt think of that

christos14:07:50

This simplifies thinks a bit. I will just remove it

p-himik14:07:37

@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)))))
Note that the :queue there is not a vector, so I have to turn it to a vector myself.

p-himik14:07:45

@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.

christos15:07:23

i had already a function

christos15:07:13

@p-himik

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

christos15:07:17

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

p-himik15:07:57

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.

christos15:07:31

not sure if i get that

christos15:07:56

the transient collection is an intermediate collection

christos15:07:41

transient access is more time consuming than regular rbb vectors ?

christos15:07:59

I thought transients were rbb vectors

p-himik15:07:53

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.

p-himik15:07:05

Also, you probably meant rrb vectors?

christos15:07:43

into uses transients

christos15:07:47

so i should use into anyway

christos15:07:56

anyway thanks

christos15:07:47

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

christos15:07:02

something like that could work

p-himik15:07:53

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

p-himik15:07:40

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

👍 4
christos15:07:08

(dec (count queue))

p-himik15:07:16

Ah, right. 🙂

p-himik15:07:42

Python-based cognitive bias.

christos15:07:59

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

p-himik15:07:28

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

christos15:07:12

sorry i dont understand

christos15:07:29

you are refering to the interceptor chain ?

p-himik15:07:21

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."

christos15:07:25

have you tried hy ?

p-himik15:07:55

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

pesterhazy18:07:33

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

8