And that is why they should be compiled, not implemented directly in main language of the project. I've made experimental yEd diagrams → CLJ(S) FSM compiler and executor (https://github.com/ul/vfsm). Simple example of its usage could be found here https://github.com/ul/ampere/tree/master/examples/simple — open resources/example.graphml with yEd (http://www.yworks.com/en/products/yfiles/yed/) to see how control logic of handler is defined. What is the real fun, that it is easy to spot an error in the logic looking on that graph. If you rewrite this state machine in textual code, you will get something harder to inspect.
четверг, 14 мая 2015 г., 6:39:02 UTC+3 пользователь Erik Price написал: > 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.
