Fork me on GitHub

Does it matter at all if all 4 API calls return before you display anything, and is there any order that matters? My assumption is that you need them all back before rendering and that order doesn’t matter, is that correct?


i'm ok with them populating as they come back


or populating when all complete


Ok, that should make it a little easier if it doesn’t matter.


I don’t think there are any real issues doing multiple dispatch from one event - if order mattered you might find useful, but otherwise I think it should be pretty safe to do them all at once.


so just generate 4 events from the ui?


when i click load invoices it knows that it takes 4 things to complete that?


Yeah, I would set it up your button would fire off the load-invoices event, and that would then fire off the API calls and whatever else is needed.


Might not need that extra level of indirection though.


wait are you saying to dispatch from the event handler for load invoices?


ui => dispatch [:load-invoice num]; (reg-event-fx :load-invoices (doall (dispatch [api1]) (dispatch [api2])...))?


Most likely you want to use either effectful handlers or the idea from


You could probably do it all from a single -fx handler, some of my gut feel for this is still stuck in the past as I did a lot of DB work the old way and my mindset still hasn’t converted. Do what feels best to you, I doubt you’ll go too far wrong.


@dpsutton we do e.g.

(reg-event-fx :load-lots-of-foo (fn [{:keys [db]} _] {:http-xhio [{:method :get :uri “a” :on-success [:a-success]} {:method :get :uri “b” :on-success [:b-success]}]}))


Oh. Didn't know it worked like that. Nice


Thanks. That's exactly what I was looking for


:http-xhrio from expects either a map, or a seq of maps.


if its a seq, it just doseq over all the maps calling the effect for each map.


I need to get around to doing some pull requests for some bugs in :http-xhrio that we found and fixed in our fork.


But should get you started 🙂


We haven't used re-frame-http-fx much in practice, we did it more as a living example (in contrast we use re-frame-async-flow lots). @yogthos said he had a problem with re-frame-http-fx also .... so very keen to get any rough edges knocked off.


Yeah, I meant to look more into that, just haven't had the chance


I think the main issue we had was with not getting a response body due to missing :response-format on the xhrio options so we provide a custom response format fn. Will look at the code later today and see if there is anything useful to push upstream @mikethompson


I want to use a third form component that uses ':should-component-update', and return false to skip rendering. In order to determine if false should be returned, I need to compare if one prop has changed compared to a value in 'db'. But as far as I can tell the db value is not something I can access from that lifecycle method. Is that correct?


@tom use a subscription ?


@tom e.g.

(defn foo []
  (let [db-value (subscribe [:the-subscription])]
    {:display-name “Foo”
     :should-component-update (fn [] (if (= … db-value) …


I was thinking about that. I just don't know if that will trigger a re-render when the value is updated. If db-value is "A" and then the prop for it is also "A" then of course I can return false. But if there's a change to "B" then it allows a render. Which would include updating db-value which might trigger another render?


The situation is that this is to allow use from a larger JSX program, so the complexity is blinding at times haha