I mentioned it in the very first post of this discussion Khalid aka DjebbZ @Dj3bbZ
On Fri, May 22, 2015 at 5:57 PM, Marc Fawzi <marc.fa...@gmail.com> wrote: > 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 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.
