# State Management Bonanza!

## Redux

**Size:** 4.3kb
**Deps:** None.
**Style:** Stripped down, functional, composable, opinionated
**Stars:** 57.3k
**Quality of docs:** Damn good.
**Tools:** redux-toolkit (10.3kb), immer(15.9kb), and react-redux(16.9kb)
**Ease of use:** Tough short-term, better in the long term.
**Speed of dev:** Same as above.
**Reliability:** Rock-solid. Redux itself has 9 well-used, well-tested functions.

### Pros

- Very small surface area (9 functions)
- Functional library (deterministic/reliable)
- Enforces functional patterns (compose/pipe style data piplines)
- Very flexible
- Extremely composable
- State subscribers (might allow us to not reload all app data after TX)
- great at organizing utilities (actionCreators, bindActionCreators)
- **BIG PRO:** Actions trigger across the entire state tree. Creates event based systems that can change state across the entire app deterministically.
- Selectors greatly limit rendering vs. Context API
- A single store and low-level composability allows us to clean up the TX process and give it more powers.
- Helps with many of the data aggregation utilities we currently do manually (ex. finding a token's data or finding a member).
- The chome extension is amazing. Allows us to see changes that happen to state, rewind, fast-forward, write actions directly into the console, and export state.

### Cons
- Can be tedious (requires lots of boilerplate w/ out reduxToolkit)
- Heavily opinionated. Enforces a strict functional approach. (reduxToolkit/Immer does take away some of this pain, but adds a lot of abstraction)
- Async is challenging. Requires Thunks.
- React/redux hooks are not functional and makes it hard to test components in isolation
- React/redux connect API is functional and good for testing, but cumbersome (invloves wrapping stateless components in stateful logic wrappers).
- My guess is that Redux will be pretty tough for new devs.
- Redux relies on us ensuring that we're following the functional mindset of redux. If we don't, it becomes an anti-pattern.
- Adds friction for hacking stuff together, new devs, or devs who aren't familiar w/ functional-style JS.

### Questions/Thoughts
- One of the biggest no-nos with Redux is that we should not have more than one store of state. If we want to turn DAO state management into a library, and the application developer would like their own central store of state, would we be forcing people into an anitpattern?

## XState

**Size:** 65.5kb
**Deps:** None.
**Style:** Very opinionated, formalized, visual, luxurious
**Stars:** 18.4k
**Quality of docs:** Pretty good.
**Tools:** @xstate/react (9.1kb),@xstate/test (13.2kb), and @xstate/inspect(8.2kb)
**Ease of use:** Tough short-term. Not sure about longterm.
**Speed of dev:** Same as above.
**Reliability:** Seems pretty reliable.

### Pros
- State machines are easily visualized in a state chart
- Statecharts can even be self-documenting (derived from code)
- Statecharts can be read by new or non-devs
- Great for conceptualizing logic and spotting errors before we even start coding.
- Comprehensive test coverage
- Accomidates late-breaking changes
- Finite state machines ensure that
- always starts with an initial state
- state can only be one thing
- specific events fire specific state changes
- State can only be changed from specific states. This is managed by transitions.
- Not only do these constraints solve application complexity by managing state, they force developers to think about modelling state, and could possibly lead to better decisions.

### Cons
- Cumbersome, requires a lot of charting and planning instead of coding.
- Heavy methodology and discipline. Will require some background learning on state machines
- Less documented and supported than Redux
- Less portable than Redux
- Modeling state using nested object statements is verbose

## Conclusions
-