How to mock server response? I'm thinking in redefine :http-xhrio on my devtools namespece. So I can mock all HTTP requests

@souenzzo can you ask in a different way? Give more information? Are you talking about stubbing out the re-frame-http-fx effects handler, maybe?

Example: GET/user - anywhere in my app I call /user I will always mock a response defined somewhere. It will be usefull to test widgets with large data and implement some stuff without have the implementation of endpoint @mikethompson

is there any way to get a value from the app db in an fx? i have an effect for sending a message over a websocket and i want to drop in a token from the db

Well, the db is still passed to the fx

Like in this snippet

(reg-event
   :my-event
   (fn [db [_ a]]
       {:http {:method :get
               :url    ""
               :on-success  [:process-blah-response]
               :on-fail     [:failed-blah]}
        :db   (assoc db :flag true)}))

(from the docs)

hmm no if you registered an fx handler, it will only be given what the handler returned under that key

in my case it's an fx:

(reg-fx
  ::ws
  (fn [message]
    ; Would like to conj a token from app-db to message automatically
    (chsk-send! message)))

ah okay, thanks guys

I’d have to check but it’d be nice if injected interceptors were run before re-frame’s dofx, this would allow to add an interceptor that would enrich the returned fx, in this case filling in the value for you

yes, that would be nice!

Unfortunately that won’t work unless you redefine reg-event-fx https://github.com/Day8/re-frame/blob/master/src/re_frame/core.cljc#L89

damn

so then i could just chuck the token in an atom somewhere and deref it in my already side-effecty fx

what could go wrong 🙂

then you should make that an fx too

Well, could you bake the token into the message before it gets passed to the handler?

I think this is a part of re-frame I've never seen before

simplest solution would be to add the token to the fx’s data indeed

i could but that's a lot of repeated code for every handler that uses my api

could also pass the whole db for convenience, let the fx handler pluck the token out

Well, I guess the follow-up question is: would it work if you called the interceptors before do-fix? Is that a feasible pull request, or would it be an api-breaking change?

this is really more of a thought exercise for me

but the good news is that i think i can do it with an interceptor

specifically, in the :after context i can edit any :effects that match my ::ws key

hey, it worked. great.

(def jwt
  (->interceptor
    :id :jwt-interceptor
    :after (fn trimv-after
             [{:keys [coeffects] :as context}]
             (update-in context [:effects :myapp.fx/ws 1] (partial cons (get-in (:db coeffects) [:identity :token]))))))

hi, pretty new to re-frame, I'm using a library called "re-frame-storage" to persist some values of state in local storage (that part does work), but I'd appreciate advice to adapt the usual db initialisation to load local storage values OR defaults?

@lessylvains hi, author here~ are you using it as (co)fx or interceptor mode?

If you use it in interceptor mode, in your init event: - check if your persisted app-db sub-key already has valid data (loaded from local storage) - if not, initialize it with your default values

@akiroz thank you I will try that 🙂

@joshk oh cool, I read the src wrong, and forgot to parse the interceptors right to left for the after functions

thanks just the same for looking

@joshkh @akiroz > but the good news is that i think i can do it with an interceptor > specifically, in the :after context i can edit any :effects that match my ::ws key Yes, that's the approach which came to my mind. BTW. I'm hoping the 3rd inforgraphic panel is useful for conveying the detail: https://github.com/Day8/re-frame/blob/master/docs/EventHandlingInfographic.md combined with the words in: https://github.com/Day8/re-frame/blob/master/docs/Interceptors.md#executing-a-chain