Clojurians Log v2

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?

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

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

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

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

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

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

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

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

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

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

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

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

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?

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.

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

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

Thanks!