Finite State Machine Observations

[zoomclub]

My thoughts after looking at the JSM and having an understanding of Vue/Vuex and a fascination with FSMs are many. Presently, most frameworks are data driven and D3/Data-Driven-Documents was the first experience I had with this revolutionary paradigm shift.

Then React came along and we all got views that were a function of state. Now, Vue/Vuex takes this to the next stage and I'm beginning to see the world as just state/info driving different types of machines (for rendering, navigation, etc).

I have pondered the FSM concept for sometime and each one is built for it's own purpose it seems. In the end I'm inclined to use as few dependancies as possible and define FSMs in the most open-ended and universal way if possible.

IMO a FSM for the purpose of navigation/transitions is just another Vuex store module, having methods for it's own unique purpose. Then states are just open ended nodes defined in a JSON (a universal format) document, which is then loaded into it's specific store module. The state nodes can specify almost anything, routes to push to the router, etc. not only transitions.

Once loaded a given node/state can be activated and subsequently processed by RxJS or standard Vuex method types to ready the state for Vue components to consume. From there it is just a matter of mapping/injecting the state into the components that require it using the Vuex provided helpers.

This is how I have distilled the FSM concept for my usage, trying my best to implement as much as possible with as few multi faceted APIs as possible. I think I'm getting better at it, especially with Vue and RxJS covering most of my bases now :)

[davestewart]

Thanks for your thoughts. I didn't notice a question in there so I assume you're just sharing?

A FSM is certainly a different relationship of state to system than Vuex/Redux, but I'll caveat that by saying I haven't yet used Vuex or Redux, so I'm somewhat limited in my observations.

However, the goal of JSM is really to manage "where" not "what", with the map of actions per state governing what you can do at any one time.

To be honest, I'm not hugely experienced with FSMs either, though have spent the best part of 15 years of my career in some way needing one, in the last 10 years being aware of them, and in most of that having attempted various ways to write one, each of them falling short and in no way being flexible or decoupled enough to use outside of the project each was written for (think nests of switch statements!).

However, recently the penny dropped and I've been able to build something that does exactly what I need it to do, in a decoupled manner, with incredibly small amounts of code! This was always the goal :)

So I see your point about using as few libs as possible, but where you explain in your last 3 paragraphs about what you need to do to set up transitions / states, this sounds like a lot of work, and a lot of application-specific code - especially when determining what transitions are available - which is exactly the problem JSM solves.

So I would be really interested to see how one would tackle a small part of an application (perhaps the signup form example) with Vuex, specifically available actions and UI updates, and exactly how much code would be needed; would you be interested in coding something up - maybe one with, and one without JSM?

I made an attempt here to couple a component with a JSM's state:

• http://statemachine.davestewart.io/html/examples/vue/vue-component.html

The prescribed relationship was to use JSM to manage available routes and navigation, and the component to manage its own state.

At some point I need to get my head round Vuex and I'll be able to better compare that with JSM, but I'd certainly be interested in having a working demo with JSM/Vuex.

I assume that is actually a possibility?

[zoomclub]

The reason I share is also because I care about your JSM, it is the most succinct JS FSM I've seen yet. I agree that "determining what transitions are available" is something that JSM solves well and without the JSM there would be more code to write.

I'm just getting into Vue/Vuex more myself but am already sold on it. There are a number of concepts on the Vue and Vuex sides that lend themselves to orchestrate transitions. These include the conditional and slot aspects of Vue, store modules and mapping of Vuex to Vue and more.

I've linked in a wizard made with Vue/Vuex below but am not implying that it could not benefit from your JSM. I'm learning that VUE/Vuex does a lot (it takes time to discover all the concepts) and that it has well structured places for data and functions and also types of functions. There are also great plugin, mixin and directive solutions built into Vue.

http://gritcode.github.io/gritcode-components/#/wizard

Based on what I'm understanding from a Vue/Vuex perspective your JSM might work really well as a Vue plugin. Between the core functionality of the JSM and what Vue offers I think there is a lot of room to integrate the JSM much more naturally and seamlessly into Vue/Vuex.

So we can not compare the JSM directly to Vuex, rather I think it is important to see it in light of the myriad aspects of Vue/Vuex. It is the concept of a FSM in the context of what Vue/Vuex offers and what it may still require that I'm really getting at.

The other aspect I'm keen on is using plain old JSON to define states and using a store module to contain all states. JSON is also a format that works with realtime databases like Firebase, so state definitions can be swappable and are not so hardcoded.

[davestewart]

How funny - for my use case (an installer for Laravel Sketchpad) I also started with a set of "wizard" components, and thought this would be the right approach.

I had slide indices, progress bars, all that jazz but it just ended up being a lot of code, and far more tightly-coupled / constrained than I wanted it to; essentially it just felt like a big, icky compromise.

That feeling of it not being right, led me to first trying Jake Gordon's state machine, then building my own. Defining and coupling a state machine to any tags or components you want, feels great in comparison!

I may have some time over Christmas to invest in checking Vuex out. I'm certainly behind the curve on this one!

As for states / JSON, when using the Vue helper, you essentially get a store for free:

http://statemachine.davestewart.io/html/examples/vue/vue-reactive.html

The next version of JSM may use classes for states, as this will allow the development of nested state machines. You'll still be able to define states using strings, but they will get converted to State classes internally. This will allow for a more OO way to run methods as well, as you'll be able to target the state directly:

state.name
state.exit()
state.getActions()
state.doSomething()
// etc