This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-31
Channels
- # announcements (4)
- # aws (1)
- # babashka (52)
- # beginners (178)
- # boot (4)
- # cider (2)
- # clj-kondo (10)
- # cljs-dev (39)
- # clojure (744)
- # clojure-europe (12)
- # clojure-germany (6)
- # clojure-india (56)
- # clojure-italy (5)
- # clojure-nl (60)
- # clojure-spec (9)
- # clojure-sweden (14)
- # clojure-uk (36)
- # clojuredesign-podcast (6)
- # clojurescript (11)
- # community-development (5)
- # core-async (4)
- # data-science (6)
- # datomic (6)
- # emacs (7)
- # events (4)
- # exercism (33)
- # fulcro (11)
- # funimage (2)
- # graalvm (29)
- # java (1)
- # joker (3)
- # lambdaisland (15)
- # malli (2)
- # meander (55)
- # mid-cities-meetup (1)
- # nrepl (8)
- # observability (4)
- # off-topic (2)
- # pathom (5)
- # re-frame (31)
- # shadow-cljs (73)
- # spacemacs (18)
- # sql (27)
- # test-check (14)
- # testing (1)
- # tools-deps (5)
- # xtdb (13)
Hi all, I'm wondering if the re-frame implementation provides a guarantee that two events dispatched via re-frame.core/dispatch
are scheduled and processed in the same order that they are dispatched. The router documentation says it uses a FIFO queue. Assuming we can treat these two events independent of all other events, is this a hard guarantee they are handled in the same order? (Clearly a more explicit guarantee would be to re-dispatch sequential events, with possibly added latency).
barring failures (e.g. an event throws an error), it is the case that events are run in order
yeah that’s true. any effects returned by an event are run in random order and may fail
they are run in order until you get to cljs.core/PersistentHashMap
at 8+ elements, at which point you might want to pass a sequence of key-val tuples to keep order
feel free to test it
yeah, that’s an impl detail of persistent hash maps. on the order of guarantees, I would mark that close to nil.
Same with providing key-val tuples. The fact that it works is a happenstance. The documentation says that you have to return a map.
most of the time you don't care about the order, but if you do, you have the option to pass tuples (no matter the size of your map). I think that's useful but it's ok to disagree
sometimes, the code is better than the documentation at explaining behavior.
If I really had to rely on the order of effects, I would just chain regular events, that each emits the corresponding effect. Follows documentation and you won't have to check the internals of re-frame on each update.
I’d probably write the effects in a promise chain and have one event/effect that runs it 😛
Agglutinating multiple effect handlers into a single one is cheating. :P
> chaining events and effects is a terrible DX
The question was about emitting the effects in the order, not about making sure that they're handled in order. So it would be like :dispatch-n [...]
and not like evt1 -> fx1 -> evt2 ->fx2 ->...
.
(defn display-questions-list [uurlid question-count]
(let [questions (rf/subscribe [:questions])]
(fn [uurlid question-count]
[:div
(doall (for [{:keys [idx question]} (zlib/indexado @questions)]
^{:key (hash question)}
[question-item (assoc question :counter idx :uurlid uurlid :qcount question-count)]))]
)))
I have no idea what indexado
is and what the rest of your app looks like, but as I mentioned, it just works for me:
(ns reagent-playground.core
(:require [re-frame.core :as rf]
[reagent.dom :as dom]))
(rf/reg-event-db :init
(fn [_ _]
{:data []}))
(rf/reg-event-db :update
(fn [db _]
(assoc db :data (map rand (range 10)))))
(rf/reg-sub :data
(fn [db _]
(:data db)))
(defn app []
(let [on-click #(rf/dispatch [:update])
data (rf/subscribe [:data])]
(fn []
[:div
[:button {:on-click on-click}
"Update"]
[:div
"Data"
(for [v @data]
^{:key v}
[:span [:br] "Item: " v])]])))