Which State Manager Should I Use?

The package comes with three types of State Managers, each with slightly different characteristics, tailored for different use cases.

	`SimpleStateManager`	`StateManager`	`AsyncStateManager`
Inherits from	-/-	`SimpleStateManager`	`StateManager`
Async set-state	No	No	Yes
`get`/`set`/`reset`/`dispose` methods	Synchronous	Synchronous	Asynchronous
Lifecycle hooks	No	Yes	Yes
Can hide values from React Dev Tools	No	Yes	Yes
Computing overhead	Very low	Low	High

`SimpleStateManager`

A bare-bones state manager.
Very fast and lightweight.
No lifecycle management.
State values cannot be hidden from React Developer Tools.
When .set calls are nested, only the outermost one will be effective. The nested .set calls will only result in a momentary state change and get overwritten by its outer .set calls right after.
Has the least flexibility and number of features, and is unlikely to have new features in future updates.
Suitable for general use cases (UIs, forms, lists, etc.) that do not require persisting state or hiding state values from React Developer Tools.
Go to API reference.

Inherits everything from SimpleStateManager.
Slightly slower than SimpleStateManager, but still responsive enough to accommodate scenarios that involve rapid key presses and mouse events.
Supports lifecycle hooks.
State values can be hidden from React Developer Tools.
When .set calls are nested, they will be triggered in order, from outermost to innermost.
Has more flexibility over SimpleStateManager and is more likely to be updated to work with new external features where it makes sense to integrate them. (For example, new features from libraries such as React or browser APIs.)
Suitable for general use cases (UIs, forms, lists, etc.). This is the default recommendation.
Go to API reference.

Similar to StateManager except .get, .set, .reset, and .dispose operations are asynchronous.
Slower than StateManager since it needs to accommodate asynchronous set-state functions.
Not suitable for scenarios that involve rapid state changes as it may result in noticeable lag.
Only use this as an escape hatch if you need to call asynchronous functions inside the set-state function for the .set method. AsyncStateManager will wait for these actions to be completed before setting the state.
- Example: calling a REST API that requires awareness about the previous state in order to derive the next state.
Go to API reference.

info

It is strongly advised to move async logic out of .set calls whenever possible and only use AsyncStateManager as a last resort.