Fork me on GitHub
#re-frame
<
2021-02-17
>
Jason01:02:20

Is there a way to short-circuit an interceptor stack as in Pedestal or Sieppari interceptors such that an interceptor can detect a condition and prevent the execution of the rest of the current interceptor stack?

phronmophobic03:02:50

@jasonhlogic, it's not something I've tried, but it seems doable in principle, http://day8.github.io/re-frame/Interceptors/#self-modifying

phronmophobic03:02:07

re-frame's interceptors are based on pedestal's interceptors, http://day8.github.io/re-frame/Interceptors/#credit

Jason04:02:05

That seems pretty... mutable but I guess it's idiomatic

phronmophobic04:02:30

in theory, an interceptor that modifies the context can be tested in isolation

phronmophobic04:02:39

since it (the modifying interceptor) receives a context and returns a context

Jason04:02:45

I've used Pedestal and Sieppari on the backend, so I understand that level of benefit.

Jason04:02:51

What I'd really like is an event-level HOF structure of some sort. The chains of events dispatching other events which spring up around (for instance) http requests are tough to keep track of

phronmophobic04:02:15

for that type of asynchrony, I would probably reach for clojure.core.async

phronmophobic04:02:56

and just have re-frame effects kick off the processes by put!ing values on channels

Jason04:02:04

I'm sure it's possible in pure re-frame if you pass around an atom parameter to act as a queue or some similar device

phronmophobic04:02:09

but there's a lot of variance in what different programmers and teams choose

phronmophobic04:02:20

I'm not fully up to date on what the best options might be. there might already be a re-frame library that does that. I found this http focused library, https://github.com/Day8/re-frame-http-fx . there may be other, more general, libraries

Jason04:02:28

i'll go read that and see, thanks

manutter5114:02:52

I’m having mixed feelings about this: We’re using the http-fx add-on to do our AJAX calls in a re-frame-friendly way, and I want to wrap that with my own effect handler (:fz-ajax) so I can do things like setting defaults for request and response format, and handling default failure cases. My first cut added :fz-ajax as a new re-frame effect, which took its opts argument, merged in its own :on-success and :on-failure handlers, and then rf/dispatch’ed to an fx handler that turned it into regular :http-xhrio.

manutter5114:02:10

It works, but it feels really dicey to be calling rf/dispatch from inside an effects handler, and I’m thinking I should re-implement this so that an interceptor takes care of converting the :fz-ajax effect into an :http-xhrio effect.

manutter5114:02:34

What do you all think? Is it worth the extra complexity to avoid calling dispatch from inside an effects handler?

p-himik14:02:39

I do the same thing and I use re-frame.registrar/get-handler for that. Formally, it's not a public API but in this case it doesn't bother me.

p-himik14:02:10

(reg-fx :ajax-io
  (fn [params]
    (assert (map? params))
    (let [http-handler (re-frame.registrar/get-handler :fx :http-xhrio)]
      (http-handler (merge {... you default values ...}
                           params)))))

manutter5114:02:48

Hmmm, that’s interesting. That’s VERY interesting…

manutter5114:02:35

Thanks!

👍 2