Ruslan, ampere looks interesting. You've taken the handler/middleware code from re-frame and combined with javelin to make ampere. Is that a fair assessment? I'll have to have a look at javelin.
Jamie On May 14, 2015, at 9:45 AM, Ruslan Prokopchuk <fer.ob...@gmail.com> wrote: > 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 <khalid....@gmail.com> 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 clojurescrip...@googlegroups.com. >> >> To post to this group, send email to clojur...@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.
