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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [email protected]. >> > To post to this group, send email to [email protected]. >> > 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 [email protected]. >> To post to this group, send email to [email protected]. >> 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 > [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
