https://github.com/piotr-yuxuan/dispatch-n-bug-mwe 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 re-frame-trace

@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

@mikethompson (partial rf/dispatch :my-event-key some-data)

Instead, just use conj

the event is a vector

conj onto the end of it

then dispatch

Also, one of these days there might be a version of re-frame where 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

I wanted events to be modelled as data, not just be args

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:

👍