Fork me on GitHub
#re-frame
<
2019-01-18
>
borkdude15:01:44

Is this reg-sub-raw stuff still the way you should use to load initial data when your component loads? https://github.com/Day8/re-frame/blob/master/docs/Subscribing-To-External-Data.md

borkdude15:01:51

it links to this document, but it doesn’t give a real solution in my opinion? https://github.com/Day8/re-frame/blob/master/docs/FAQs/LoadOnMount.md

borkdude15:01:54

is the suggestion to dispatch the event when the user navigates to the page, instead of doing it in the component itself?

mbertheau15:01:48

@borkdude I believe you shouldn't hook something up on component load. Instead, hook it up on the event that causes that component to load.

borkdude15:01:10

that makes sense I guess.

borkdude15:01:54

we have one page with a lot of components, like 10 of them. I don’t think we want to put the initial loading of those events into the “navigated to the page” event, that would become quite convoluted. there’s a certain elegance in putting those events together with the component

Jenny Kwan16:01:42

Total n00b observation, but given that the onMount intention is to load data prior to rendering, it does make sense to advance app-db state with a loaded? flag to then cause the component to load/render.

lmergen18:01:12

@borkdude what I have done is, inside my route event handler, do a multi method call to discover additional “route events”: for your page, I would then inject a bunch of additional events that need to be dispatched that initialize data for the components

lmergen18:01:55

it felt quite natural to me to use multimethods for this and leads to nice decoupling

lmergen18:01:26

the route event handler then uses the :dispatch-n fx handler to dispatch any additional events

borkdude18:01:31

@lmergen could you post a snippet example?

lmergen18:01:02

absolutely, one moment

lmergen18:01:05

(defmulti route-events (comp first :route))

(defmethod route-events :default
  [active-route opts]
  (log/debug "no route events for active-route: " (pr-str active-route)))
... then somewhere below, my route event handler:
(re-frame/reg-event-fx
  ::set-active-route
  default-interceptors
  (fn-traced [cofx [opts]]
             (let [events (or (route-events opts) [])]

                {:dispatch-n events})))

lmergen18:01:10

and then somewhere, i can have for example something like this:

(defmethod route-events :connectors
  [{:keys [panel] :as opts}]

  (match [panel]
         [[:connectors :install :dropbox]]
         [[::receive-install
            {:my :data}]]           

         [[:connectors :install :twitter]]
         [[::oauth-events/access-token-flow
            {:more :data}]]

         :else
         [])))

lmergen18:01:55

(these were events that needed to be triggered on oauth callbacks, for example)

lmergen18:01:06

but you can use it for your situation as well

borkdude18:01:31

cool, thanks!

lmergen18:01:50

you might be able to do something like this with fx handlers ? not sure

lmergen18:01:01

if you find a better / more data driven approach let me know

Drew Verlee21:01:29

assuming i have two event handlers

handler a:
{:db do-x :dispatch [:b]

handler b:
{:db do-y}
Can i expect the do-x update to always happen before the do-y update?

lmergen21:01:27

yes, I believe that handler :b will even be called in the nextTick

Drew Verlee21:01:44

Thanks, i can't imagine it working any other way.

joelsanchez21:01:48

well. you lose that guarantee if you have more than 8 keys in the map

joelsanchez21:01:15

because the map implementation changes from PersistentArrayMap to PersistentHashMap

joelsanchez21:01:28

cljs.user=> (seq  {:a 1 :b 2 :c 3 :d 4 :e 5 :f 6 :g 7 :h 8 :i 9})
([:e 5] [:g 7] [:c 3] [:h 8] [:b 2] [:d 4] [:f 6] [:i 9] [:a 1])
cljs.user=> (seq  {:a 1 :b 2 :c 3 :d 4 :e 5 :f 6 :g 7 :h 8})
([:a 1] [:b 2] [:c 3] [:d 4] [:e 5] [:f 6] [:g 7] [:h 8])
cljs.user=>

joelsanchez21:01:39

of course who would have more than 8 effects at once

lmergen21:01:33

in this case the flow is guaranteed because of the :dispatch fx usage, not?

lmergen21:01:46

one is a function call, the other is an async event dispatch

lmergen21:01:16

seems pretty clear to me this is unrelated to the map’s ordering