This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (117)
- # boot (8)
- # cider (22)
- # clara (3)
- # clojure (79)
- # clojure-italy (3)
- # clojure-spec (34)
- # clojure-uk (34)
- # clojurescript (74)
- # cursive (7)
- # datascript (5)
- # datomic (28)
- # defnpodcast (1)
- # dirac (9)
- # docker (25)
- # duct (1)
- # emacs (14)
- # fulcro (67)
- # graphql (1)
- # hoplon (15)
- # jobs (4)
- # juxt (6)
- # off-topic (76)
- # parinfer (3)
- # re-frame (25)
- # reagent (4)
- # rum (6)
- # shadow-cljs (1)
- # spacemacs (30)
- # sql (15)
- # unrepl (36)
- # yada (1)
I’m pretty it’s not a bug in
re-frame, however I find the behaviour described in this project very unexpected. I expect events to be sequentially processed as a queue, but this project exhibit something that looks like it’s different. Any hint?
@piotr2b when events are dispatched, they are placed into an FIFO queue.
Hmm. My comment above doesn't exactly address your question/problem, BUT that repo's README has an
Aw, found it! section ... so I assume you are good now?
BTW: my new suggestion (to almost everyone) is to observe your app's functioning via
@danielcompton: In the new version of re-frame-trace, would it be possible to have a dropdown that lists all of the epoch events? I took a quick look at at the code around it and it looks complex enough that I figured I check if there were any fundamental blockers before putting much time in to investigating it. Also, I'm loving the information in the new event panel!
I’m curious about the intention behind using a vector as the argument in re-frame dispatch and subscribe functions? It makes it impossible to partial without wrapping. I’m also curious as to any issues I might run into if I did wrap the dispatch and subscribe to make it possible to partial.
@caleb.macdonaldblack I'm not sure what you mean by "to partial"
So I can't answer the second part of your question.
But, regarding the frist part ... events are data ... I chose a
vector because visually it has less noise than a
map. The only two choices were vector or map.
map would have become my choice if I thought events were going to be complicated, but they are generally simple
(partial rf/dispatch :my-event-key some-data)
Instead, just use
the event is a vector
conj onto the end of it
Also, one of these days there might be a version of
dispatch takes a 2nd parameter
Ahh okay so the reason for it being a vector is to future proof it when and if dispatch ever needs a second parameter?
Which would mean an update like that wouldn’t break any existing projects
Partially, yes (pun intended)
data is a more powerful substrate than functions.
data is the ultimate in late binding.
So thats really interesting because functions that take an arbitrary length of params should probably just take a vector to make them easier to change later.
Unless the function is extremely unlikely to change such as some of the core functions in clojure
events to be modelled as data, not just be
Yea I can see that too. So you could pass a vector in, make some changes and dispatch without needing to use
apply for example
This perspective was at the back of my mind (although it took a while for me to realise what was guiding my thinking) https://github.com/Day8/re-frame/blob/master/docs/MentalModelOmnibus.md#on-dsls-and-machines
Thanks, I definitely learned something here. :thumbsup: