this looks like fun https://github.com/cdorrat/reduce-fsm
;) On Wed, May 20, 2015 at 7:26 AM, Marc Fawzi <marc.fa...@gmail.com> wrote: > Yup, well captured. > > On Wed, May 20, 2015 at 6:58 AM, Khalid Jebbari <khalid.jebb...@gmail.com> > wrote: > >> You would want it if you want to inspect/debug/transmit/replay the whole >> the state of your application. Having nothing encapsulated and everything >> in a global state permits this. >> >> Khalid aka DjebbZ >> @Dj3bbZ >> >> On Wed, May 20, 2015 at 3:51 PM, Jamie Orchard-Hays <jamie...@gmail.com> >> wrote: >> >>> For local state, I mean state that has to do only with the component >>> itself, nothing to do with the data itself. For example, if I have a >>> component that can switch between editing/reading states, I can't imagine >>> why I would want this information stored outside of the component itself. >>> >>> Jamie >>> >>> On May 19, 2015, at 11:58 AM, Daniel Kersten <dkers...@gmail.com> wrote: >>> >>> 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. >>> >>> >>> -- >>> 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.
