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.
