---
# System prepended metadata

title: Connect Rebuild

---

# Connect Rebuild 

### The problems
- Code is clean in the context, but raunchy in the utils
- It's hard to configure the networks
- We can't configure connect to work only for one network (needed for standalone DAO apps and templates)
- I want to be able to use Connect without the UI (so I can use custom UI in my app)
- Connect data served from context could be easier to work with (ex, chainId is string | null | undefined.) 


### The Solutions

**Configuration**
- [x] Test if devs can configure their networks, and if it doesn't work, then create the paths to do so
~~networks dropdown. Locks in DAOview.
- [x] Build lifecycle methods
- [ ] Once UI is separated Test if I can use connect w/out props. Consider making a template with material UI (create separate issue). 
- [ ] Test if I can use context with a different RPC (might need until deploying on new network)

**Packaging**
- [x] Refactor out Context and non-reusable utils to ``connect-context``
- [ ] ~~Refactor our Connect UI to ``connect-ui``~~
- [ ] ~~Refactor layouts and create configurable routing pattern to~~ ``exoskeleton`` Make issue, keep in ``connect-ui`` for now. 
- [x] Refactor all keychain related data to ``keychain-utils``


**Housekeeping**
- ``isValidNetwork`` and ``ValidNetwork``should only be used to test if the network is a possible network. This isn't really all that useful in anything besides keychain types. 
    - [x] Create an AppNetwork type that is an array of network id keys derived from the network config
    - [x] Create a isAppNetwork type that runs **inside the context** and tests if a given string is one of the app's supported networks. 
    - In the interest of getting on with our lives, let's make this non-breaking so that ValidNetwork and isValidNetwork still work. That way the current apps will still work as expected
    - We can begin to use ``isAppNetwork`` where its useful
- See if we're still using the bundled keychain structure (Network config), find any instances of it and remove. Just use readable, static data. 
- Keychains are good, but it will require that we update the chainId properties manually if we support new networks. 
- [x] Correct mark NETWORK_DATA as HAUS_NETWORK_DATA as it pertains to our own networks, not a dev's networks
- [x] Rename TEMPORARY_RPC to HAUS_RPC
- [x] Move RPCs to utils
- [x] NetworkData should have RPCs
- [x] Remove HAUS_RPCS and try to use network data
- [x] Replace RPC_ENPOINTS in admin/utils/constants with RPCs from connect
- [x] Remove addKeychain Utils
- [x] Amalagmate explorer links
- [x] Move all keychain data into keychains utils folder
- [x] Try to replace all instances of NETWORK_DATA in UI with ``networks`` from connect so users can data from networks that we don't support
- [x] Do the same for RPCs where applicable
- [x] Replace all instances of TEMPORARY_RPC
- [ ] Remove RadixColors import in deps
- [x] Clean up confusing connectWallet pattern
- [x] Rename CONTRACTS => CONTRACT_KEYCHAINS
- [x] ~~Rename HausConnectContext => DHConnect~~
- [x] Rename HausConnectProvider => DHConnectProvider
- [x] Rename useHausConnect => useDHConnect
- [x] Rename HausLayout => DHLayout


**For Later**
- [ ]TXBuiler uses HAUS-RPC, should we allow the user to pass their own network config inside? Currently, if a dev wanted to decode action data, it would require them to use our static RPC pattern
- [ ]While we're in TXBuilder, we move all the decoding utils over to utils. 


