I just discovered it! 70 messages in this thread ;) A tcp server (one of the examples) is nothing like the scenarios in the UI but this type of reducing is what i was converging to, not for UI though...
Sent from my iPhone > On May 22, 2015, at 9:24 AM, Khalid Jebbari <khalid.jebb...@gmail.com> wrote: > > 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. -- 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.
