Javascript State Machine 2.4

My javascript-state-machine library has been in hibernation for a little while - as have I - but we sleep no more! Starting with a small point release - 2.4 - to clean up a few loose ends:

• improved npm install instructions.
• switch to uglify-js for building minified version.
• fix for javascript error when running in jasmine/node (issue #88)
• exclude build files from bower install (issue #75)
• ensure WILDCARD events are included in list of available transitions (issue #93)
• fix FSM getting stuck into “*” state when using double wildcard (issue #64)
• add function to return a list of all available states to help automated testing (issue #54)
• state machine hides callback exceptions (issue #62)

The Future

As mentioned in the previous release I feel that this library works well for it’s intended use case. It is mature, stable, and well tested. This 2.x release branch is - I think - a nice, small, self contained library.

However, some companies have requested new features to support more complex use cases:

• Composable State Machines - Allow state machines to be nested (e.g. composed) of other state machines so that large monolithic state machines can be broken down into more manageable components.

• Conditional Transitions - Allow events to specify conditions that must be met for the transition to be allowed.

• Dynamic Transitions - Allow events to specify a function for the target to state so that it can be decided dynamically at run-time.

• Observable Transitions - Replace the lifecycle callbacks with an observer pattern so other interested party can subscribe and be notified of lifecycle events.

• Promise Based Asynchronous Transitions - Replace the legacy ASYNC callback behavior with a modern Promise-based system and allow any of the lifecycle events to become asynchronous.

• State History - Persist all state changes in a stack to allow for easier back/forward (or undo/redo) functionality.

• Improved Introspection - Improve introspection methods to allow callers to dynamically query the FSM for the list of all states, all events, events allowed from the current state, states reachable from the current state, etc.

• Improved Documentation - Provide more in depth documentation and more examples.

These features are fairly significant and likely to break backward compatibility and therefore justify a Major version bump to 3.0. I don’t yet know which features will be prioritized - so feel free to vote for your favorites in the comments below.

I’m also (tentatively) considering building version 3.0 under a dual Open Source/Commercial license where the majority of features will be available for free under the open source license, while the more complex features will be available, along with guaranteed support, under the commercial license…

If you have any thoughts feel free to comment below, or email jakesgordon@gmail.com