---
tags: v3, Product
---

# Moloch Pack Working Notes

## Hooks

Optional context comes with the hooks
- allows to load dao id and chain outside of params
- stores filters and sort order
- any list hooks need to follow the proposals

### Next steps

- sam to do members

## Design Considerations

- Getting daoid and daochain. Single DAO app use constant variables. Multi-DAO apps use the URL. We need a solution that satisfies both constraints.
- [ ] Try adding daoid and daochain to connect?
- [ ] DAOChain and DAOId as props?
- [x] Connect with optional props as alternative?

~~*I added daoChain and daoId to props of connect. It's non-breaking. ~~
*I created a new Context that exists within

- Remove unnecessary friction by replacing all ValidNetwork and EthereumAddress types with string.
- new ticket

## Macros

1. review admin app to define component scope
- any other macros from dao apps we've built?

2. start to define apis
- where do we use hooks vs. prop drilling
- cannont rely on router/params or context

#### Proposal list

- can define new proposal types
- can pre seed with a filter? limit
- pass desired filters in for filter list
- search


#### Proposal card
- details + action
- custom proposal type


stretch:
- expanded details section (from prop details page)
- pass in a face plate

### Proposal action data


### Proposal history


### Vault card
- pass menu items prop


### Members list
- can we configure the columns
- types hell
- or do we need to hard code for now
- upgrade to tan table?
- delegate modal can come over
- pass in action panel - where you can send a link to a form in your app


### STRETCH: Member detail page/rage quit

### Future
- look into storing forms in the hooks context
- might want its own store
- ties into static data planning
- target dao finds proposal data in ifps by hash
- proposal lego is a single ipfs hash