Fork me on GitHub

Favorite FSM (or similar) for re-frame? I know of re-state and kee-frame


Hi, is there a way to make sure that one event is finished and updated the state before I trigger another event?


To expand a little bit, I read that dispatch-sync runs right now. Does that mean that every dispatch run after dispatch-sync can assume dispatch-sync updated the database beforehand?


Does anything prevent you from just using the :dispatch effect in the first event handler?


1. dispatched events are placed in a queue and are processed FIFO. 2. Each event is processed completely, including app-db updates, before the next event is processed. 3. A dispatch-sync event jumps the queue and is processed (both synchronously and completely ) before any other event in the queue is processed. 4. There are very few cases where you need to use dispatch-sync Does that answer your question?

👍 4

@U051MTYAB So from a theoretical point of view code like this:

(do (dispatch [::foo/bar]
  (dispatch [::baz/buz]))
will place the events in a FIFO making sure that the first event will update the database first. Okay, that makes sense. It also helped my understand my problem better. So I have code like this:


(dispatch [::events/initialize-db])
(dispatch [::events/load-initial-data])

(defn init-user []
  (dispatch [::events/do])))
Is it possible, that due to the asynchronuos nature of javascript, the last dispatch is triggered before the dispatch from my init-user function?


JavaScript is async only if you ask it to be. Neither re-frame nor CLJS do that, so you should be good.

👍 4

Okay, I was unsure about that. Thank you both 🙂

David Pham12:06:57

Are there any guidelines on how to keep your system maintainable with re-frame in large systems? I think about name space keywords

David Pham12:06:36

and keep things untangled, but I don't have a lot of experience for large systems


I’ve found that drawing conceptual boundaries help a lot =)… IE: Handle file stuff in one place etc, but then make sure that all the parts of a component stay together. Happy to do a longer form example of this if that isn’t super clear? Just realised mikethompson added some advice in the main channel, I suppose I’d be an advocate of putting all related code together…

David Pham12:06:34

I usually mix. Components usually are in the same file, while big panels or views are split.


Yea I can see that, it’s really useful however to make sure that you also group behavioural functionality in the same way, which means the “api” of your system is small and easy to understand…


Some disagree with this advice and prefer to put all code related to a panel in one .cljs (and not split across views.cljs and events.cljs and subs.cljs). They say that works better for them.

David Pham12:06:11

So you keep simplicity by limiting the reach of the events?

Ray Stubbs15:06:44

Any problems with doing something like this in re-frame to make dependencies more explicit? Any particular reason keywords are used instead of symbols?

👀 4
👍 4

It seems good to me, I wonder what other re-frame people think