In the infuriating style of answering with not-quite-the-answer ;): Number 2 is more clojure-y as it makes things more self-contained/pure.
I would also triple check that the order in which events are dispatched are the order in which they are executed. Dispatch is asynchronous so but it might be asynchronous and FIFO, but I would double, and then triple check that that is a public contract. Don't forget that changes in a react environment aren't really instant - they happen on some internal browser refresh event, so actually you might not have a problem at all :). (newbie, so take with a good dose of salt and vinegar). On 3 April 2015 at 11:11, Rafał Cieślak <ravici...@gmail.com> wrote: > I'm writing a tic-tac-toe game (hot seat, not over the Internet) using > re-frame and I'm wondering what's the best approach to handling certain > actions that depend on a certain transformations of state. > > A simple example, if a player clicks on a cell, I have to: > > A. Change the owner of that cell to the current player. > B. Change the current player, so that the next one can play. > > Let's say I dispatch the click as an event (obviously) and in its handler I > treat those two mentioned actions as events and dispatch them, too. > > If they both read the current player from the app-db, a certain coupling is > introduced: if I call B before calling A, the owner of the clicked cell is > going to be changed not to the player that clicked on the cell, but to the > next player. > > There are a few ways that I can deal with that: > > 1. Just dispatch them as separate events as I decribed and introduce the > forementioned coupling (I have to remember to call these events in a certain > order). > 2. In the cell click handler, read the current player from the db and pass > it as an argument to those two events. Now I don't have to worry about the > order in which they'll be called. > 3. Instead of calling A and B from within the cell click handler, call only > A in the handler and then call B from within A. I guess that's a pretty bad > solution (I just coupled B with A even more), but it also removes the worry > about the order of calls. > > Honestly, I came up with the second solution during the writing of this post > and I feel it's the most clean one, it feels the most functional from all > three and I guess it's the standard method of dealing with problems like this. > > Anyway, I'd like to hear your opinions, how the second solution may turn out > to be bad in the future, and maybe even get to know different ways to tackle > that problem. > > Also, I wonder what's the preferred approach to handling multiple operations > in a handler, because I can either dispatch many events from within it or > call a bunch of functions on the db in a -> macro, see > https://gist.github.com/ravicious/fb189aa45b7784624485 > > -- > Note that posts from new members are moderated - please be patient with your > first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojurescript+unsubscr...@googlegroups.com. > To post to this group, send email to clojurescript@googlegroups.com. > Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
