Recommendations

Many state machines

We strongly recommend that you do NOT try to implement one humongous state machine for your whole app. Large state machine are hard to build, debug and maintain.

Rather we recommend that you have as many state machines as you find useful.

To help you think about this lets discuss the different types of state your application has:

• Global State

• Session State

• Screen State

• Widget State

Global State

Global state is normally a reflection of your persistent storage such as your application's database.

You don't need to model your global state in a state machine as you can simply query your database to discover its current state. You may need to cache your database but that's an optimisation issue and not relevant to what state is about.

Sometimes you may want to create a FSM for the state of a entity or a group of related entities.

For example a customer may go through different states such as; trial, customer, inactive, overdue, suspended, terminated. In this case it may be useful to have an FSM that is used to transition a customer between these states.

Session State

Session State tends to revolve around a user interaction with the system. A user logs in and we create a Session. It can be useful to create an FSM to track the sessions current state and to perform transitions from one state to another (logged in -> logged out).

You can then subscribed to an FSM2 stream to reflect these changes in other parts of your app is simply query the sessions state via a call to StateMachine.isInState.

Screen State

Screens, Pages, Routes, Views, or whatever you want to call them tend to present the user with a related data set (e.g. a CRUD screen for maintaining users).

As the user navigates around the Screen you may need to track what state the user is in; Listing, Editing etc.

I wouldn't normally use an FSM for these simple screens as using setState and Providers are usually sufficient to track the state of the screen.

There are however plenty of exceptions. I'm currently working on a registration wizard and the no. of possible states is crazy. Having an FSM to track where the user is in the process really makes it easier to code and easier to ensure that the process is correct via static analysis and using the FSM2 visualizer.

Widget State

Screen state is often enough to track a widget's state by using a combination of setState and a Provider.

But again, like Screen State, you may often have a widget that is particularly complex, and having an FSM to track its transitions can be useful.

Whole of Application State

This is what I'm not a fan of, a single state machine that attempts to describe the state of an entire application.

I suspect that the reason we have some many alternate state providers is that they are attempting to do too much.

Keep things simple, use a state machine where it makes sense.

Don't use a state machine just because everyone else is.