## DAO State

### Options for finite state

### Store at the page level
**Pros**

- Properly scoped to the view

**Cons**
- Would only make sense if we're storing portional state at page level
- Would require some sort of caching.
- Would likely need finite state like dao name everywhere within the dao scope

### Store at the context level

**Pros**
- Easier to reason about
- Convienient
- Easy to implement
- Easy to maintain.

**Cons**
- None, unless the state belongs to a part of the app that is rarely used.

### Options for infinite state

Infinite state (don't know the real word) is some sort of state that could be infinite, and thus could cause major problems loading in data.

Luckily, the new designs allow for strict control over what the UI needs (ex. no activity feeds, voters in separate modal, etc).

For each type of DAO state that requires us to bring in a limited amount of items, we need to store the proposals that are currently being viewed, the pagination level, the filter, and the sort.

### Store at the page level
**Pros**
- Easier to reason about
- Properly scoped to the view

**Cons**
- Harder to persist if the user is clicking around (ex. going into details, then back)
- Would require some sort of caching unless we want to fetch ever time someone clicks back and forth.
- Can potentially get messy managing view.
- Challenging for updating after TX.

### Store at the context level
**Pros**
- Pretty damn convinient to load in all the proposal, member, metadata, boost utils from one context. Very powerful feature to offer devs.
- State persists if user is clicking around. It does so naturally without need for extra caching
- Should fetch nicely after TX. Might see some challenges if filters and sort is left on after TX. We should decide how we want to handle that.
- Can still build so that page view is what causes initial load.

**Cons**
- Potentially harder to reason about if unorganized
- Potentially harder to reason about if 2 views access the same state (ex. Proposals, those cards we had for UH view in allies).
- Would therefore want separate sections for state
- There's a lot of state in one place.
- Less customizable, becuase we'd be doing all the fetches in one context we'd need to make sure that there's a way to customize them to some degree using optional props.
- Would likely require a hook to keep things organized.
- Hard to extend new slices of state. This is where Redux would be better. Not impossible though.

### Why I like keeping at context level more
- Pays off well for the next app (repeatable)
- Less caching, challenges updating state
- Cons can be mitigated with careful design.
- We can use hooks to manage common actions across infinite state (filter, sort)
- Reasoning about scope will be easier if we're consistent.
- Extending to have modular loaders will be hard with context, but definitely not impossible.
- Extending for modular loaders is likely not priority for now. Most DAO interfaces will need members, proposals, metadata. Ones that need more can always build separately before a modular loading system is built.
- We can still export each item separately so that a more complex project can use page view or complex loading patterns in the way they see fit. In fact, they'd get the same value out of this library if we used page view.

### Store Single Item State on Page view

We'd still need to address things like a single proposal or member view. I'd say this is a good candidate for page level as we don't really need state to persist as often.

Ex. It's a lot more likely that a user is going to look at a proposals page twice than a single proposal page.