---
tags: Product
---
# **App Context Spike**

### Purpose
Explore an alternate version of the current PokemolContext:
- Mulitple, hierarchical contexts in an effort to minimize component rerendering and break out logic
- Enable simpler methods for the app to react to user/web3Modal provider/DAO changes
- Dao navigation
- User Network changes
- User account changes
- User Connect/Disconnect
- Declarative useEffects describing the change the context is reacting to

#### POC scope
- Single Hub View and Dao view
- User connect
- Dao data loading
- Proper init of user and dao when moving between 2 different daos and the dao and hub in all possible network/connected states

## Hub
Scenarios
- Initial app load/reload
- Navigating from a DAO back into the hub

### Connected flow
1) If we do have a cached provider OR when the user connects with web3Modal
- get cached provider if available on app load
- if not get new provider when user connects with metamask or other web3Modal supported wallet

2) User/web3Modal init
- 'App Network' gets set to network from user/web3modal provider
- Get 3box data for user
- Update user state

3) Make graph/api calls to get dao data related to the user
- HUB_MEMBERSHIPS graph query on all networks
- This data is also used when a user is in a dao view
- Daohaus api has some metadata that can be used to hydrate the dao data if needed

*Dao contract services not needed at this point and no web3 calls are made here based on the current UX.*

### Disconnected flow
**When we don't have a cached provider**

1) Default 'App Network' to mainnet
2) Right now we're just displaying a message for the user to connect, but we will eventually want to display some featured dao data
- This will need to make api/graph queries across multiple networks as above, but not scoped to the user address.
- We don't haveus for this yet, it might even be hard coded data, we'll see.

### DAO
Scenarios
- Initial app load/reload on a DAO route
- Navigating from the hub
- Navigating from another DAO

### Connected flow

1) Determine if the dao address (from the route) is valid
- daohaus api call to get metadata of the dao, network is in this data
- Update dao data

2) Load dao graph data
- Graph call scoped to the dao address
- Update dao data
- Some 3box api calls are made in graph resolvers
- If this is on an initial load and the user/dao networks match we also need to make a grpah query scoped to the user address to get all their daos for the dao switcher component

3) Init the dao contracts
- Can init with the user/web3modal provider IF the provider network matches the DAO network
- If those don't match we are logging the user out/clearing user state data and initializing the dao contract with readonly web3

4) Init the user wallet
- Again, the user/web3modal provider and the dao network need to match
- This makes web3 calls and update userwallet state

### Disconnected

1) Same as above, but dao contracts will be created with readonly web3 and no user wallet is created