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