State Machine Utility (using native prototype property) with LockableDoor Demo

[saad]

StateMachine Utility (developed using native JavaScript Object.prototype property)
https://github.com/sshams/puremvc-js-util-statemachine

LockableDoor Demo
https://github.com/sshams/puremvc-js-demo-lockabledoor

The Demo also demonstrated a simple solution for communication between component and a Mediator that PureMVC JS community has been struggling with or have questions about, it's a Delegation Pattern in JavaScript using closures for communication between viewComponent and it's Mediator. Inspired by Objective-C Demo where the viewComponents communicates to it's Mediator via a Delegate. Have a look at the following.

https://github.com/sshams/puremvc-js-demo-lockabledoor/blob/master/js/view/ApplicationMediator.js
https://github.com/sshams/puremvc-js-demo-lockabledoor/blob/master/js/LockableDoor.js

Inside onRegister a closure was defined and is passed to the viewComponent, viewComponent only knows about functions within that closure and has no information about it's Mediator hence it's loosely coupled, that closure has reference to Mediator that can then call function of the Mediator. Closures are big and powerful in JavaScript and solved many problems.

This approach eliminates the need of any 3rd party utilities/libraries for dispatching events or Signals, you're free to use any for their benefits but my intent was to develop the demo in it's purest form and without depending upon any library, and just utilizing the power of the language and the PureMVC framework itself.

[puremvc]

I like the idea of delegation to solve the component->mediator communication problem.

In Flash, where we have a built-in Event system, so it was convenient to decouple the component entirely from its mediator. In JS, we have to build our own event system or make use of some 3P lib. In that light, passing a closure to the component is a reasonable approach. Much better than giving the component a direct reference to the mediator.

[saad]

Thanks Cliff for your comments.

In context of StateMachine, I've been thinking about an Asynchronous State Machine, on the client side if entering and exit guard notifications trigger asynchronous processes (calling remote services), let's say checking retries for a Simple Form Submission (from your State Machine Presentation), so State Machine has to wait for the response (CANCEL or OK) to determine transitions.

What's your idea on how could that work or what else should go in an Asynchronous State Machine?

[puremvc]

Actions happen and the state changes; it's async already. Beyond that, handling retries is a stretch of the State Machine's responsibilities.

Instead, the command that deals with an enter or exit guard notification should be responsible for executing the retry policy.