:fx is for any effects (including dispatching other events, but also your own custom effects): https://github.com/day8/re-frame/blob/master/docs/Effects.md

using fx rather than dispatch-n is preferred according to API docs: https://day8.github.io/re-frame/api-builtin-effects/

oh thanks for the reply 🙂

If you call it in a reactive context, it will be removed from the cache right when the view is unmounted.

and what about the not-reactive context?

You can write your own version of subscribe that uses private but simple API of re-frame.

> no handler registered for effect I assume it's followed by :dispatch-sync? dispatch-sync exists in re-frame itself as a function. But it doesn't exist there as an effect.

@U2FRKM4TW thanks for responding! Do you mean the way I am calling :dispatch1 is not right ?

I mean that the effect :dispatch-sync simply does not exist.

But :dispatch does exist - that's why it works.

it is the namespace re-frame.core right ?

Nope. Effects and functions are completely different things. The fact that there's a function re-frame.core/dispatch and the fact that there's an effect :dispatch registered in re-frame.fx are completely unrelated. There's also a :dispatch-later effect, but there's no dispatch-later function.

ohh ok, what if I have the scenario, where one of my event is depends on another, How can I achieve it ?

shoud I use interceptor with after effect?

Depends on what you mean by "depends". :) Ideally, you would just refactor your code in such a way so that dependent functionality is tied together by composing functions.

You're getting a coeffect and returning an effect in your interceptor. Since it's :after, you should probably stick to just effects and ignore coeffects unless there's no db coeffect.

So in essence, your interceptor is completely overriding the db effect.

here context is assoc with :effect :db but the return will contains both coeffect and effect right ? also I refereed code from https://github.com/jgdavey/minesweeper/blob/main/src/main/minesweeper/app.cljs#L185 which I did it in similar way

let me know if my understanding is wrong!

> but the return will contains both coeffect and effect right ? Yes. But the code that you link to does not take db from coeffects - it does so from effects. And unconditionally, so it assumes that the corresponding event handler always returns the db. Unless something has changed in re-frame that I haven't seen.

hmmmm

A block of code is worth a thousand words. ;)

(reg-event-fx :failure-http-using-token (fn [{:keys [db]} [ result]] ; retry grabbing token with refreshtoken {:db db :http-xhrio {:method :get :uri (utils/flow-api-url) :params {:r @(subscribe [:refresh-token])} :format (ajax/json-request-format) :response-format (ajax/json-response-format {:keywords? true}) :on-success [:save-token] :on-failure [:failure-http-result]}}))

this is the 2nd call where the failure has occurred on the 1st call

(reg-event-fx :save-token tokens-interceptor (fn [{:keys [db]} [_ return-json]] (js/alert return-json) (let [data (:data return-json)] {:db (assoc db :tokens {:token (:accessToken data) :refreshtoken @(subscribe [:refreshtoken])}) :dispatch [:set-active-nav :settings]} )))

here is the :save-token

the (js/alert return-json) fires, the :dispatch doesn’t

and the tokens-interceptor doesn’t either

very strange behavior, because previously i did an assoc-in db :tokens to only update :token, but then my :refresh-token was wiped out

{:db (assoc-in db [:tokens :token] (:accessToken data))}

(interceptor that saves the tokens to localstorage, somehow wiped it in localstorage, only saving :tokens :token)

First of all, just in case, I'm gonna mention that using @(subscribe ...) in an event handler is an anti-pattern. If you open the JS console, there will be warnings from re-frame about it. Another thing worth pointing out is that js/alert is blocking. I don't really know how you test it, but until you close that pop-up, none of the following code will be executed. Apart from that, I don't notice anything obviously wrong. But I would definitely suggest using js/console.log instead of js/alert to debug things.

good point

i’m using the alert to ensure i get popup’s in expected order

(reg-event-fx :save-token tokens-interceptor (fn [{:keys [db]} [_ return-json]] (js/alert return-json) (js/alert (:tokens db)) (js/alert db) (let [data (:data return-json)] {:db (assoc-in db [:tokens :token] (:accessToken data)) :dispatch [:set-active-nav :settings]})))

is what I have now

I would still use js/console.log - it does preserve order. It even supports groups with js/console.group and js/console.groupEnd.

the return-json: provides the result the (:tokens db) is NULL 😞 the db seems to only contain the map of :token en :refresh-token

hmm, i believe that is where the problem is, it’s not the full db

Check your interceptor.

(def tokens-interceptor [(path :tokens) ->local-store])

(def ->local-store (after tokens->localstore))

(defn tokens->localstore [tokens] (tap> tokens) (let [actual-tokens (:tokens tokens)] (.setItem js/localStorage “tokens” (str actual-tokens))))

(a (tap> in there for debugging reasons)

Well, there you have it - the db there is actually (:tokens app-db) because of that path interceptor.

but that should only fire AFTER all events took place?

i mean in my other reg-event-fx called :save-tokens, it works as expected

A path interceptor replaces the :db coeffect in its "before" stage and puts the resulting effect in the right place it its "after" stage.

hmm, for some reason (js/console.log) doesn’t seem to be working for me in Safari - no output

i’m confused then why this works as expected: (reg-event-fx :save-tokens tokens-interceptor (fn [{:keys [db]} [_ return-json]] ; (js/alert (str “SUCCESS: ” return-json)) (let [data (:data return-json)] {:db (assoc db :tokens {:token (:accessToken data) :refreshtoken (:refreshToken data)})})))

also has same interceptor, also does a keys on db and assoc’s to the db

> hmm, for some reason (js/console.log) doesn’t seem to be working for me in Safari - no output Maybe js/console.log is overwritten by something - you can check by executing console.log(1) on a different web page. If that doesn't work, maybe your JS console filtering is set to something. I don't use Safari myself so can't tell. > i’m confused then why this works as expected: My bets are on it not actually working like it should. In the end, it will result in the db having 2 nested :tokens.

could i solve this by removing the (path ) you think?

Of course.

so i removed it

and i can’t tell for sure yet if it’s working

but the tokens->localstore fn now has the entire :db that’s for sure

i’m trying (js/console.log "a") in the REPL, but no message anywhere either hmm

while (js/alert "a") gives instant reaction in the REPL browser window

a, finally got it working in the REPL browser window

in that window, there was a filter

localstorage token and refreshtoken now seem to work 🙂

thanks, removing (path solved it!

i really thought, looking at the re-frame todomvc that it would do everything after the event ha, not before

for some reason, refreshing the entire browser window

now it seems that js/console.log works

very strange

however, THANK YOU very much! has been bugging me for hours finding out what went wrong

No problem, glad it worked. :)