---
# System prepended metadata

title: State Conversation (6/7/22)
tags: [' state', ' blacksmiths', v3]

---

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