I don't think it implies local state, necessarily, although it may benefit from it. I think alternatives can be modular too.
For example, re-frame's approach of a central place to store data is like a Blackboard system, which may even help modularity, not hinder it, because modules don't need to know anything about each other - only that the data they read and write is in the central place and may be (transparent to the modules) be accessed/updated by multiple modules transparently (and hopefully gets validated eg through a schema or constraint system to prevent one module from writing data that breaks another module). On the other hand, local state implies encapsulation and encourages strict interfaces to access it, which can also help modularity. In my personal experience this has (more often than not) led to tightly coupled modules instead, however. I personally prefer the re-frame single-place-for-data approach because in my opinion its benefits outweigh its disadvantages, but perhaps I've just been doing local state wrong :) (actually pretty likely!) PS: It'll probably be some time before I get a chance to read Horrocks' book. If anybody knows of any similar content available on the web for me to read in the meantime, I'd love to hear of it! On Tue, 19 May 2015 at 14:34 Jamie Orchard-Hays <jamie...@gmail.com> wrote: > I agree. The word that came to mind while reading your comments, Daniel, > was "modularity". Does modularity imply local state? Pondering... > > Jamie > > On May 18, 2015, at 1:26 PM, Khalid Jebbari <khalid.jebb...@gmail.com> > wrote: > > I like how you break up the state machines, it has sense in web app. Page > 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM > associated with it, the higher level FSM knowing just the higher level > state of all widget displayed. Mmmh... Interesting. > > Le 18 mai 2015 à 19:13, Daniel Kersten <dkers...@gmail.com> a écrit : > > From my understanding of it: > > Use higher level states and decouple them somewhat from the data. > > For example, games do have lots of dynamically changing data. In a modern > shooter you might have dozens of characters with positions, orientation, > velocity, health information, weapons, ammunition, etc all of which can be > constantly changing. And that's just taking the characters into account. > > I wouldn't go and build a state machine that enumerates all of the > possible transitions from a "twelve characters with done distribution of > attributes in this location moving in that direction" state. I'd break it > down so that each character has a high level state like "seeking powerup" > or "running". > > Probably not a great example although it does illustrate that you might > have a hierarchy of state machines. In the game example, the highest level > might be something like "in play" or "paused" and the lowest might be an > each characters "firing weapon". > > In client side web app, you could say that each configuration of data is a > state (the re-frame readme mentions that you could think of the app-db like > this), but I think that's too fine grained to be useful. > > Instead I'd define higher level states (possibly in a hierarchy). I'd ask > myself, regardless of the data available, what are the logical states that > a user could be in and for each one, what are the actions that they can > perform (and what state does each action transition them to). > This could be as simple as pages and links, but with a rich single page > application it's more likely finer grained than that. Maybe what dialogs or > widgets are accessible. > > Again, you could then layer these into a hierarchy of state machines. > > One advantage of this is you always know what a user can do at any given > time because you can look at what state they're in. > > I think of FSM states as orthogonal to the data, not as the data itself. > The states dictate what data is accessible and what can be done to it; the > data doesn't dictate what state the application is in. > > I suppose terminology gets confusing, but this is the approach I'm toying > with. I'll see how that goes :) > > But yeah, needs more thinking. > > On Mon, 18 May 2015 16:55 Marc Fawzi <marc.fa...@gmail.com> wrote: > >> Games are ideal candidate for straight-forward FSM implementation since >> you normally download the data at game load time and from there on you have >> a *relatively* small set of states that can be transitioned between based >> in user input. You can even apply state minimization techniques to reduce >> the total number of states. >> >> But in a web app you are continuously grabbing data from the server and >> that data is generated based on not only user input but also the state of >> the server side database and that server generated data would modify UI >> side app state and you have to account for all possibilities so the total >> number of states could grow wildly if your UI is data driven (where the >> state of the UI depends on the data in non-trivial ways) but even if your >> UI state dependence on server data was a trivial relationship you could >> still end up with a huge state diagram for the simplest viable business app >> if you include templating the view as part of the UI FSM on top of business >> logic. You could segment your app into micro apps and that will help >> regardless of whether you're building the app as FSM or not. >> >> And what if the state transitions are probability driven? How many states >> will you end up having to chart? >> >> Not convinced YET... >> >> Sent from my iPhone >> >> > On May 18, 2015, at 6:57 AM, Sean Tempesta <sean.tempe...@gmail.com> >> wrote: >> > >> > Hi Khalid. I found your topic interesting so I thought I'd chime in. >> Regarding your comments on routing: >> > >> > So, under normal conditions, the initial URL sets the FSM in motion (as >> an event). We could call this entry point a routing state. Afterward, the >> state transitions are controlling the urls (not the other way around), >> right? >> > >> > Outside of normal conditions (ie. people copying and pasting links into >> random parts of the system), you also just send the url to the routing >> state and then switch to a new state based on whatever rules and >> definitions you've set. >> > >> > Or maybe I'm missing something. I haven't built an FSM in a while. :) >> > >> > Sean >> > >> >> On Monday, May 18, 2015 at 6:07:22 PM UTC+8, Khalid Jebbari wrote: >> >> Trying to push forward the discussion about Web UI with state >> machines. I came up with the following decomposition of the core components >> of a web application : >> >> >> >> - application state >> >> - application data >> >> - business logic >> >> - ui logic >> >> - event processing >> >> - presentation layer >> >> - routing >> >> >> >> In this schema, I think the application state is the real core, >> because every other components is directly related to it, at least if you >> use a state machine. I came up with the following model. >> >> >> >> - application data : related to application state because both can >> easily represented as data. If we want a web app that is completely >> state-driven (I want this, for debugging, testing and time-travel >> capabilities), simply merge the data and the state in the same data entity. >> >> >> >> - business logic/ui logic : in a state machine there's the notion of >> "actions" executed with each transition (where necessary). So the logic >> could just be executed by the state machine itself. >> >> >> >> - event processing : a state machine can be event-driven, and this a >> perfect match with a web app since the web (and any UI for that matter) is >> inherently event driven. So the event/input of the state machine could just >> match the event triggered by the user, as well as custom events if >> necessary. >> >> >> >> - presentation layer : simply display the current app-state as >> HTML/CSS. In the React.js model, it would simply mean updating the app >> state and letting React render everything. >> >> >> >> - routing : this is where stuff gets complicated in my mind. In a >> proper application, lot of state is derived from the URLs. But not all >> state, for instance whether a modal is displayed or not, or whether a form >> is validated client side or not isn't tied to a URL. Which tend to let me >> think that there's some kind of hierarchy in the state machine. The URLs >> could be represented as events as well in the state machine, but could >> happen at anytime, whereas other events and related transition depend on >> the current state in a state machine. So it's like you have a top-level >> state machine for URLs, and each URL has its own state machine for all >> interactions in the page. Maybe page-state machine could be refined in >> multiple levels state machines too, not sure about that. It seems like >> Hierarchical State Machine may help here, but I haven't studied the subject >> yet at all. >> >> >> >> What do you think ? >> > >> > -- >> > 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. >> > > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to a topic in the > Google Groups "ClojureScript" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojurescript/7STtgK5QiIc/unsubscribe. > To unsubscribe from this group and all its topics, 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. > > > -- > 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.
