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.
