Finite state machines are a useful modeling tool, but when implemented in code they can involve a lot of boilerplate and complexity. These days I prefer Rx-like paradigms for sophisticated handling of asynchronous events.
e On Wed, May 13, 2015 at 5:54 AM, Khalid Jebbari <[email protected]> wrote: > Hello everyone, > > As a Javascript web developer, I'm thinking more and more about a good way > to design interface so that I don't create a mess. Because I think the > current "state of the art" of web UI development and frameworks is still a > big mess. > > React.js and the CLJS wrapper around them help a bit but not that much I > think. > > My goals are the following : > > - construct the complete UI logic outside of anything web related, so that > it's testable without a browser and usable in other contexts (CLI, > back-end, scripts, whatever) > - being able to *visualize* the logic without having to read all the code, > through diagrams and other means. > > I've heard in several places that state machines are a good way to handle > such cases, since they're inherently event-driven and the web is too. > > So I start researching. The wikipedia page ( > https://en.wikipedia.org/wiki/Finite-state_machine) and the various > linked pages are very instructive and indeed explain that a FSM can be used > to model UI interaction. I found this 3-parts article series from IBM ( > http://www.ibm.com/developerworks/library/wa-finitemach1/index.html) that > implements a tooltip using a state machine. > > Then I found 2 clojure libs that helps design a state machine : reduce-fsm > (https://github.com/cdorrat/reduce-fsm) and automat ( > https://github.com/ztellman/automat). Both have the *very* nice feature > of being able to generate a state diagram from the code, but only automat > provides support for CLJS. > > I think a state machine fits very well with React.js and as so the various > CLJS wrappers, since : > - in an event-driven state machine, there's a loop listening to events. > This event-loop is naturally provided by web browsers > - defining strictly and formally the available states helps reduce bugs > and maintain the application > - the output is always defined by the combination of the input and the > current state, which is *exactly* what the render function of React > component are about : displaying DOM based only on the state of the > component. > > Since this state is purely data, and CLJ/CLJS are kings when it comes to > data, the benefits would be to be able to test the logic a component > outside of the DOM and have components that simply emit events (with the > associated payload) to the state machines. > > The various libs in the CLJ/CLJS ecosystem can help greatly : > - the aforementioned automat lib to design and visualize a state machine > - Prismatic's Schema (https://github.com/Prismatic/schema), Herbert ( > https://github.com/miner/herbert) and the likes to formally specify data > types/shapes that come in and out of the state machine > - test.check to generate lots of input to the state machine and check the > output. This can't replace UI testing, but can complement it a lot. Note > that Herbert is de facto compatible with test.check > - The various React.js wrappers to take this state and simply project it > to the DOM. > > This post is basically a reflection on the subject that I wanted to share > and not lose in my mind since I'm new to state machines, and a question to > the community : did you already use a state machine to program a web UI ? > Successfully ? With which tools ? What do you think of the various libs > (aka "the stack" lol) proposed above ? > > I know that a simple state machine trivially implemented with no libs at > all and may seem often overkill. This post from Spotify ( > https://www.shopify.com/technology/3383012-why-developers-should-be-force-fed-state-machines) > and this response ( > http://www.skorks.com/2011/09/why-developers-never-use-state-machines/) > are really interested real world examples of usage (or not) of state > machines. > > Phew ! It was long, I hope I wasn't boring and I'm looking forward to your > answers. Let's discuss ! > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
