I’ve noticed that apps often embed ad-hoc , with information about the current status spread out throughout . I wrote a small helper for working with finite state machines in called . In this post, I’ll go into: Redux finite state machines reducers Redux redux-machine An example of a finite state machine and how to it with redux-machine implement Advantages to using redux-machine redux-machine Example This is a very simple example of a state machine for working with data fetching, which will help show how to use redux-machine: finite state machine for handling API call state in Redux In words: INIT is the initial status When the status is `INIT` and the action type is `FETCH_USERS`, the machine transitions to `IN_PROGRESS` status. When the status is `IN_PROGRESS` and the action type is `FETCH_USERS_RESPONSE` or `FETCH_USERS_FAIL`, the machine transitions to the `INIT` (initial) status. I use the term “status” instead of “state” to avoid confusion with “state” in the Redux sense. So and are statuses. INIT IN_PROGRESS Here’s how you can implement the state machine with redux-machine: state machine implemented with redux-machine The special part is the symbol, which transitions the reducer to a different status. When the status is , acts like . When the status is , acts like . become INIT fetchUsersReducer initReducer IN_PROGRESS fetchUsersReducer inProgressReducer Redux-machine keeps the current status in the store in a non-ad-hoc and explicit way. It stores the current status in the store with the STATUS key. For example, when the status is , the value of “STATUS” is “IN_PROGRESS.” IN_PROGRESS An app can have arbitrarily many reducers created with redux-machine, and these reducers can be nested. This is helpful because any non-trivial app will have state machines within state machines. For example, if the main flow of the app is: a simplified main flow for an app then the statuses in fetchUsers will only be relevant when the main app status is LOGGED_IN. Advantages of redux-machine redux-machine makes the current status explicit and keeps your state in the redux store. Keeping all state in the store is useful for: Debugging: the entire state is easily inspectable. redux-machine is also compatible with . time-travel debugging Communicating status to the user. For example, with a loading spinner when the request is active or a “logged in” indicator when the user is logged in. and are good at modeling user workflows, but store status outside of the redux store. redux-saga redux-observable Request for Feedback I haven’t used extensively yet, so would welcome feedback and suggestions. redux-machine
