Thanks, Khalid. Jamie On May 20, 2015, at 9: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.
