---
# System prepended metadata

title: State Management Bonanza!

---

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