add and handle on-success.

That was my intuition, but that’s going to force me to get them all in reverse,

I wouldn’t be able to only ::fetch-user

not without creating another effect

if you are using re-frame-http-fx then you still need to do this

https://github.com/day8/re-frame-http-fx#step-3a-handling-on-success

in fact, even if you didn't use it, all you get with fetch is promise, which has to call another event in .then anyway

So, the situation I’m running into is something like fetching widgets belonging to the current user, but if that user data isn’t loaded yet, I need to fetch it first

In the setup you’re describing, I think, I’d have to have ::fetch-user-then-widgets and ::fetch-user or I wouldn’t be able to fetch the user without also fetching the widgets

problem begins when the data being fetched depends on the result of the previous fetch, then callback hell happens and there seems to be no good solution for this in re-frame

I can adapt that http-fx to take a more complex version of :on-success that I think will solve my problem.

That’s kind of what I’ve noticed.

What I’m thinking is adapting :on-success to take a vector of things to dispatch on-success instead of just those args.

That way I could call the root level event ::fetch-user-widgets but it would first call ::fetch-user then ::fetch-widgets

I think I can make that work.

I had this problem recently and solved it like this:

(rf/reg-event-fx
 ::fetch-address
 (fn [{:keys [db]} [_eid {:keys [user on-success] :as m}]]
   (if-let [user-id (get-in db [:x :y :z :users user :user-id])]
     {:http-xhrio {... something that uses user-id
                   :on-success (conj on-success [...])}}
     {:fx [:dispatch [::fetch-user {:user user :on-success [::fetch-address m]}]]})))

if you have the data you need in the db, you do a fetch, if not, you fetch the data you need and go back to current event in the on-success

That’s good. I might be able to get away with that, but it’d get messy at 3 layers of fetching 😓

good old cps

it's clojure, everything can be done with macro

but it's really not that bad, I also have a few layers of fetch and it's quite verbose, but it works and still follows the re-frame philosophy

if it hurts you too much, you can always use core.async in event and return nil

then you always have only two layers

(rf/reg-event-fx
 ::fetch-xyz
 (fn [{:keys [db]} [_eid {:keys [user on-success] :as m}]]
   (go
     (let [user    (<! (fetch-user user))
           address (<! (fetch-address user))
           xyz     (<! (fetch-xyz address))]
       (rf/dispatch [::fetch-xyz-successful xyz])))
   nil))

it goes completely against the re-frame philosophy, but it works

@UJL94RYSW If you really want to minimize events you can make a state machine

[:map 
  [:user-info-status 
    [:enum :not-asked
           :loading-widgets
           :failed-to-load-widgets
           :loading-user-record
           :failed-to-load-user-record
           :success]]]

say your state looked like that

you can have an event that loops back on itself

(rf/reg-event-fx ::advance-state (fn [{:keys [db]} [_ info]] {:fx [[:http-xhrio (if (... (= status :not-asked) ...{:uri "/...request-widget.../") ...

but truly its probably best to just manually write out every situation

you make your first request due to "user interaction A" - event is called ::user-interaction-a

on success you move to ::successfuly-fetched-widgets

on failure you move to ::failed-to-fetch-widgets

then in ::successfully-fetched-widgets you make another request to fetch the user

and move from there to ::successfully-fetched-user or ::failed-to-fetch-user

the duplication you will have between ::user-interaction-a and ::successfully-fetched-widgets is the specification of the request to send - assuming you check if you already have widgets at that stage

but you can always make a function for that

(defn fetch-user-request [...]
  {:uri "/api/.../user/..."
   ...})

(rf/reg-event-fx
  ::user-interaction-a
  (fn [{:keys [db]} _]
    (if (already-have-widgets? db)
      {:fx [[:http-xhrio (fetch-user-request ...)]]}
      {:fx [[:http-xhrio (... fetch widgets ...)]]})))

...

(rf/reg-event-fx
  ::successfully-fetched-widgets
  (fn [{:keys [db]} [_ resp]]
    (... {:fx ... (fetch-user-request ...) ...})))

if that makes sense

my position is to {:fx [:dispatch [::fetch-user don't on this

in my mental model events aren't "helper functions"

Just as an additional note of what I ran across sometime - kee-frame has a reg-chain to make this a bit less painful. Something like this may also be a neat solution? https://ingesolvoll.github.io/posts/2018-04-01-learning-kee-frame-in-5-minutes/#event_chains I never used it myself though

Looks like that is now its own small library https://github.com/ingesolvoll/re-chain