statecharts 1.0.1+1
statecharts: ^1.0.1+1 copied to clipboard

Statechart implementation consistent with Harel notation and the SCXML spec

Statecharts #

Why another state machine / statecharts package? I was looking for something akin to the Flutter view hierarchy —  declarative, immutable, and a good candidate for implementing SCXML.

Let's take a simple lightswitch example.

The data model #

class Lightbulb {
 bool isOn = false;
}

The statechart #

const turnOn = 'turnOn';
const turnOff = 'turnOff';
final res = StateResolver<Lightbulb>();
///
final countedLightswitch = RootState.newRoot<Lightbulb>('lightswitch2', [
 State<Lightbulb>('off',
     transitions: [
       res.transition(
           targets: ['on'],
           event: turnOn,
     ],
     onEntry: (b, _) => b!.isOn = false),
 State<Lightbulb>('on',
     transitions: [
       res.transition(targets: ['off'], event: turnOff),
     ],
     onEntry: (b, _) => b!.isOn = true),
]);

Execution #

final engine = await Future.value(lightswitch)
           .then((ls) => Engine.initial<Lightbulb>(ls, bulb));
// Execute an event
await engine.execute(anEvent: 'turnOn');

Disclaimer #

This is not an officially supported Google product.

0
likes
120
pub points
13%
popularity

Statechart implementation consistent with Harel notation and the SCXML spec

Repository (GitHub)
View/report issues

Documentation

API reference

License

Apache-2.0 (LICENSE)

Dependencies

built_collection, built_value, collection, logging, meta, ordered_set, quiver

More

Packages that depend on statecharts