Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Loopback Component Finite State Machine

NotificationsYou must be signed in to change notification settings

fullcube/loopback-component-fsm

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

42 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Greenkeeper badge

Circle CIDependenciesCoverage Status

This loopback component provides a finite state machine (powered byhttps://github.com/vstirbu/fsm-as-promised) for loopback model instances, enabling precise control over when model instance methods may be called.

When a model method that is controlled by the Finite State Machine is called it will set a global lock that will prevent other copies of the same instance from being transitioned whist the existing transition is still underway. The state machine governs which state transitions may take place at any time given the current state of the instance and handles state change persistence on completion of a given transition.

Installation

  1. Install in you loopback project:

npm install --save loopback-component-fsm

  1. Create a component-config.json file in your server folder (if you don't already have one)

  2. Enable the component insidecomponent-config.json.

{"loopback-component-fsm": { }}

Configuration

  1. Define a state machine events in the mixin configuration for you models.
"mixins": {"StateMachine": {"stateProperty":"status","settings": {"allowForce":true    },"events": [      {"name":"activate","from":"none","to":"active","transitionOptions": {"skipBeforeSave" :true } },      {"name":"cancel","from":"active","to":"canceled" },      {"name":"reactivate","from":"canceled","to":"active" },      {"name":"expire","from": ["active","canceled" ],"to":"expired" }    ]  }}

Options:

  • stateProperty

    [String] : The name of the model's state property.(default: 'state')

  • settings

    [Object] : Settings used to control state machine operations. Currently the only supported option isallowForce which when set totrue makes it possible to carry out an otherwise invalid state change by passing in{ force: true } at method call time. This option can also be set per event.(default: {})

  • events

    [Array] : A list of events available to the state machine. Refer to theFSM As Promised documentation for details on how events should be defined.(default: [])

Implementation:

For each event in the State Machine, a series of model notifications will be sent - one for each stage in a transition - in the following order:

callbackstate in which the notification executesdescription
fsm:onleave{stateName}fromdo something when leaving state stateName
fsm:onleavefromdo something when leaving any state
fsm:on{eventName}fromdo something when executing the transition
fsm:onenter{stateName}fromdo something when entering state stateName
fsm:onenterfromdo something when entering any state
fsm:onentered{stateName}todo something after entering state stateName (transition is complete)
fsm:onenteredtodo something after entering any state (transition is complete)

You can act on any of these transition stages by observing the notification. For example:

MyModel.observe('fsm:oncancel',ctx=>ctx.instance.doSomething().then(()=>ctx))

If you intend to perform an asynchronous operation in a given transition stage, your observer should return a promise that resolves to thectx argument that was passed to it. Otherwise, you should simply return thectx object.

Return values

Thectx object will be passed through the entire transition call chain and returned to the original caller. If you would like your caller to receive something other than the fullctx object you can setctx.res which will be returned instead.More information

Usage

Prototype methods will be attached to model instances for each of the named events in your mixin configuration. Forexample, the above mixin configuration will result in the following methods being added to MyModel.

  • MyModel.prototype.activate
  • MyModel.prototype.cancel
  • MyModel.prototype.reactivate
  • MyModel.prototype.expire

These methods all accept a first argument that is a settings object that is used by the fsm to determine how it functions (eg passing{ force: true } (seeallowForce above). All arguments will be available from within the various fsm notifications.

MyModel.findOne().then(instance=>{log.debug(`Current state is:${instance.state}`)// Current state is: activereturninstance.cancel()}).then(instance=>{log.debug(`Current state is:${instance.state}`)// Current state is: canceledreturninstance.reactivate({force:true})}).then(instance=>{log.debug(`Current state is:${instance.state}`)// Current state is: active})

In this example, a model instance is loaded from the database and a finite state machine is initialized using the current status of the model instance. The instance is then transitioned to the canceled state, then back to the active state.

More Information

Please refer to theFSM As Promised documentation for more detail on the internals of the state machine implementation.

About

Loopback Component Finite State Machine

Topics

Resources

Stars

Watchers

Forks

Packages

No packages published

Contributors2

  •  
  •  

[8]ページ先頭

©2009-2025 Movatter.jp