---
# System prepended metadata

title: '**App Context Spike**'
tags: [Product]

---

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



