Jason 2021-02-17T01:58:20.129500Z

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?

phronmophobic 2021-02-17T03:49:50.130600Z

@jasonhlogic, it's not something I've tried, but it seems doable in principle,

phronmophobic 2021-02-17T03:51:07.131200Z

re-frame's interceptors are based on pedestal's interceptors,

Jason 2021-02-17T04:06:05.132500Z

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

phronmophobic 2021-02-17T04:10:30.134300Z

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

phronmophobic 2021-02-17T04:11:39.135900Z

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

Jason 2021-02-17T04:12:45.137Z

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

Jason 2021-02-17T04:16:51.139500Z

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

phronmophobic 2021-02-17T04:19:15.141900Z

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

phronmophobic 2021-02-17T04:19:56.143Z

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

Jason 2021-02-17T04:21:04.144900Z

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

phronmophobic 2021-02-17T04:21:09.145100Z

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

phronmophobic 2021-02-17T04:23:20.146700Z

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, . there may be other, more general, libraries

Jason 2021-02-17T04:24:28.148Z

i'll go read that and see, thanks


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.


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.


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

p-himik 2021-02-17T14:29:39.155100Z

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-himik 2021-02-17T14:30:10.155600Z

(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 ...}


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