# 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](/visualise-your-fsm.md).

## 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.

###

###

###

##

###

###


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://fsm2.onepub.dev/recommendations.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.