---
tags: v3, state, blacksmiths
---

# State Conversation (6/7/22)

- To redux or not?
- How often will our state change?
- Update state in chunks based on actions such as polling
- How would complex queries for things such as proposals change things, and where would we want this to live?
- How would redux help here?

## Digging Deeper

- Context is great for "low write, high read" since it triggers when things are updated
- Redux is better for "higher write" use cases
- If we don't see many "high write" use cases we could reach for redux
- Can we set a framework for when we'd want to bring in Redux (to manage a high write usecase)?
- What would this look like?
- When should I use Redux?
- We do have a lot of state throughout the app, but less true for v3 than for v2
- SDK resolves a lot of this since state stays up to date (especially with regards to pagination)
- Instead of having to serve all data across the entire app, we're able to be more selective and we have better tools for managing state
- How often is our state updated?
- Seems to be pretty infrequent due to how slowly DAOs update
- What is our criteria for deciding to move to Redux?
- We're talking about this for Core UI (most likely, at least)
- We saw the problems of relying on Context in v2 and we'll need to be aware of this threshold in v3 and this'll determine where and when to reach for Redux
- If Core UI starts to get messy we can then reach for Redux
- As things are being architected we could even make the decision early on if we start seeing some of the criteria being hit

## Feature Packages

- Distributing state across packages such as DAOhaus Connect, theme state, etc.
- Distributed stores -- how does this work with Redux?
- One Redux store per app -- working with a single store still works with this approach

## Layering in Context

- Sprinkle in different Contexts as needed in a modular way
- What if we have to pivot on a moments notice? Would having modular Contexts work?
- Can do this with Redux as well
- Modular Redux:
- Don't need multiple stores -- can put the state at different points within the single store
- Initialization functions add in the reducers into the single store
- Still composable -- don't need multiple stores (whereas flux is multiple stores)
- Con:
- Dependencies across contexts isn't always straight forward, so when state is updated it's not always clear what the dependencies are
- How would everything come together and integrate if we decide we need to use Redux?
- Redux store is another Context provider in a certain way -- so we wouldn't necessarily be crossing between Context and Redux
- We'd have to do this through composition within the different components
- Framework link: https://redux.js.org/faq/general