---
tags: v3, scratch
---
# Haus SDK - June Refactor
## Goal
Incorporate feedback, learning and further research into a refactored library.
## Detail
### Current sdk concerns
1. query
scoped subgraph queries with data hydration, filtering, pagination, ordering
haus-data
query class
2. profile
ens and ceramic profiles
profile class
3. commons
utilities w/ no other dependencies
4. abis
5. contracts
client to return contracts and abis
haus-contract-service
- returns abis
- type protected contracts
- addresses (or in commons)
7. Pull all types out?
### feedback/learnings
We have to initialize Haus with a list of networks just to make a query. Definitely unnecessary. Don't think it's a pattern we should spread across the apps. A good solution would be to have all queries that aren't dependant on RPC available as modular separate export that is also included in Haus.
can we easily break up these sections and allow importing single concerns?
- gnosis pattern: https://github.com/safe-global/safe-apps-sdk
can we combine abis, contract addresses and contract instances into a single section of the sdk?
- w/ typechain protection on the functions
what other concerns will we want
- dao database schema/helpers
should profile queries come with dao memberships?
## Reference
### @dao-data package work:
1st rage & report on the spec:
https://hackmd.io/wtDwRLeVTsepeDjeiQ0lyg?edit
https://hackmd.io/4uk2ySsVTQit8a1ScxjLVw
Subgraph query exploration
https://hackmd.io/hnzEi34fTiiyZGJYe-jN_A
v2 backend
https://hackmd.io/o7cVYOO4SxiZ03afDDufqA
dao database
https://hackmd.io/Z9X2yRlhSbaurnP5FVA-LQ
### third party sdks
https://github.com/orcaprotocol/orca-sdk
https://github.com/nounsDAO/nouns-monorepo/tree/master/packages/nouns-sdk
https://github.com/superfluid-finance/protocol-monorepo/tree/dev/packages/sdk-core/src
https://github.com/safe-global/safe-apps-sdk
## Naming/Grouping
HAUS SDK (Standard Development Kit)
| Utilities | |
| --------------------------- | ---------------------------------- |
| @daohaus/common-utilites | helper functions, constants, types |
| @daohaus/contract-utilities | abis, contract addresses, typed contract client |
| Data | |
| --------------------------- | ---------------------------------- |
| @daohaus/dao-data | READS: query, profile |
| UI | |
| --------------------------- | ---------------------------------- |
| @daohaus/ui | react component library |
| Features | |
| --------------------------- | ---------------------------------- |
| @daohaus/daohaus-connect | react wallet connect context, profile data and ui |
| @daohaus/tx-builder | WRITES DATA and react transaction lifecycle context |
| @daohaus/form-builder | react ui form legos |
| more eventually... | daocontext, ui table-builder, proposal display ui |
## Next steps/tickets/ideas
- apply the getOrCreate pattern to graph events
reference: https://github.com/nounsDAO/nouns-monorepo/blob/master/packages/nouns-subgraph/src/utils/helpers.ts
v3schema: https://github.com/HausDAO/daohaus-monorepo/blob/develop/apps/v3-subgraph/schema.graphql
- add etherescan lib or into the sdk somewhere
- looking through the baal library - there are some really good typescript patterns in the nouns that can be applied to to make the library easy to reference - a top level getContractsForChainOrFail would provide accessible dot notation for all the contracts we want to load
https://github.com/nounsDAO/nouns-monorepo/blob/master/packages/nouns-sdk/src/contract/contracts.ts
it maps back to the types here https://github.com/nounsDAO/nouns-monorepo/blob/master/packages/nouns-sdk/src/contract/types.ts
- move abi and baal into the same library maybe?