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.
