This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-01-18
Channels
- # aleph (1)
- # announcements (2)
- # aws (4)
- # beginners (73)
- # boot (2)
- # boot-dev (3)
- # cider (6)
- # cljs-dev (40)
- # clojure (64)
- # clojure-austin (2)
- # clojure-belgium (1)
- # clojure-dev (25)
- # clojure-estonia (1)
- # clojure-europe (16)
- # clojure-italy (11)
- # clojure-nl (4)
- # clojure-spec (90)
- # clojure-sweden (2)
- # clojure-uk (105)
- # clojurescript (58)
- # core-async (10)
- # cursive (23)
- # data-science (1)
- # datascript (3)
- # datomic (14)
- # duct (11)
- # fulcro (48)
- # graphql (1)
- # hyperfiddle (3)
- # kaocha (95)
- # liberator (1)
- # lumo (6)
- # nrepl (1)
- # off-topic (14)
- # onyx (2)
- # overtone (8)
- # portkey (3)
- # re-frame (31)
- # reagent (6)
- # shadow-cljs (185)
- # sql (12)
- # tools-deps (6)
- # vim (6)
- # yada (224)
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
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
is the suggestion to dispatch the event when the user navigates to the page, instead of doing it in the component itself?
@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.
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
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.
@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
it felt quite natural to me to use multimethods for this and leads to nice decoupling
the route event handler then uses the :dispatch-n fx handler to dispatch any additional events
(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})))
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
[])))
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?Thanks, i can't imagine it working any other way.
well. you lose that guarantee if you have more than 8 keys in the map
because the map implementation changes from PersistentArrayMap to PersistentHashMap
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=>
of course who would have more than 8 effects at once