Blacksmiths v3 Working Session #1

--- tags: v3, working session, notes --- # Blacksmiths v3 Working Session #1 - Agenda: https://hackmd.io/OwQa8aH_R7mBVjc4IDz6cg - Goals: - Identify items to turn into specific tasks ## Initial Tasks - What do we need to do to begin turning UX specs into stories and specific stories for folks to work on? - How can we split teams and identify who works on which areas? ## Initial v3 Scope (Reference v3 Scope Doc) - What are we initially building? - **POC of Summoning App with features**: - Hard mode summoning app - v1 of subgraph, DH Baal contract, Baal summoner contract - Rage versions of component library and SDK/utilities - Design: UI Design & UX Specs - **Simple Hub application**: - List of DAOs user is in - (Design will need to take a pass at this) - Dig into our data SDK to explore and support fetching for 2 main scenarios: - 1) Scoped to a user - 2) Scoped to a DAO - **Core DAO UI**: - As we move along we can dig deeper into this ### Summon & Hub Design Review - Review the summon designs - Review data inputs/outputs - Identify micro/macro components to put into the component library - Repeat this process as we go - ## What can we start with? ### Ops - Build out GH Actions and deployment targets (Keating) - Libraries to `npm` and frontend to Skynet - Domain set up for Skynet deploys: `alpha.summon.daohaus.club` - GH Actions/Deployment Pipelines: - Component library - Subgraph deployment - Serverless deployment - Monorepo setup - Point to internal filepaths and alias - Packages: - Subgraph - Research local Graph deployment - Local Graph node for development - UI/Component library - Baal Contract (down the line) - How can we simplify the Baal repo and make it more straightforward for folks? - Can we release Baal as a `npm` package similar to OpenZeppelin? - Research how to maintain connection to initial Moloch Mystics repo will require research - Do we want all of this in our Rage repos? - Local development docs - Do a session to make sure folks are on the same page - Set up the `env` - README for each package at a basic level - How to get started with the Monorepo? - Anything going into Rage repo should be willing to deprecate - Anything built for prod should live in regular monorepo - Figure out QA - Common linter/prettier configurations - Ensure everyone is aligned and using these - Do a session to ensure that everyone is able to run things locally - Sync folks usage (can also sync up with `.vscode` setups) - Component Library notes: - (add these back, was talking so need to revisit notes!) ### General Thoughts on Haus Libraries - Give alpha version of AriaKit a test in addition to ReachUI and RadixUI - Andy having issues with AriaKit alpha -- may be too early, but going to pair with Keating to check this out - What do we want to call these? - How will we handle cards that have a lot of unknowns -- how do we communicate this w/o it slowing progress? ## Activities and Questions - How do we want to transition Rage apps to Sage apps? - What does this look like? - How/when do we transition? Are there different teams? - Rage (alpha) -> beta -> release (v1) - Milestone -> step back and identify what needs to happen while transitioning? - Tests, documentation, share learnings, etc. - What other app boilerplate stories can we write? - What routes are needed for an app? - What pages are needed? - Navigation - Basic layout - Can create an `nx generator` that is DAOhaus specific when we identify common layouts - How can we identify and leverage common patterns and pull these into our libraries? ## How to Split Teams? - May be awkward at first -- this'll evolve over time - Patient early on, but worth exploring at an initial grouping - **Contract/Subgraph** - Sam - dekan - Keating - **Summon App Rage** - Jord - Andy (overlaps with component library) - Output: - Playing with initial version of component library - Data SDK / utils -- pull out utils as they're being used - Will SDK include interacting with s3, subgraph, contract? Any third party data service? Does this include tx legos? - How do we want to update the tx legos? - Read/transform - Does this also come with a set of utils? - Encode/action/working with ABIs - **Component Library** - Andy (starting on the micro elements of component library) - Jord (starting on the macro elements) - Planning to meet in the middle as their work converges - **Hub Rage App** - Component library (basic components) - Andy - More data library work - Keating/Sam? - **Data** - Sam - Keating - Jord - Conducting group review as we build this out to identify patterns ## Baal Summon UI Review (Rage) - (Figma walkthrough with comments) - Potential confusion on ERC20 name/symbol and how it shows in the app (name of token vs. display name in app) - UI around Rage Quit: - List of tokens, which do you want to Rage Quit? - Proportion of RQ so not all or nothing - How do we want to handle ignoring spam tokens? - Data pulled in form: - Native currency (likely hardcoded) - Leverages user submitted data earlier in the form -- local state - Shamans: - Hide if we publicaly release -- not having available during Summoning - Tables (macro component) that unifies this - Need non RegEx way to handle this - Build table UI easily, but also handling and crunching the data into format needed by Baal contract - (Not for Rage) but being able to handle CSV value inputs that'll split and generate the table UI - Visit the docs? -> Loom video of someone summoning? - What should this be, especially since it's mostly DH folks using this? - Integration with Poster with the HackMD having an embedded video (IPFS link?) - Look into service for video hosting - (Down the road) Poster for Docs - Poster should be immutable but docs change often, so this may not be the best usecase - Can these pull in existing content and render it? - Components: - Inputs that we're styling (and multiple states) - Input, Textarea, Select, Checkbox, Radio, Tooltip - Can also optionally include functionality for integration with forms (this has pro/cons) - Input, focused, demonstrations for different states for Radio and other components - Buttons - Button states - Primary, secondary (text button) - Title and Text - Separation of semantic and presentational - Accordion - Dropdown/multi-select - Table - Global Connect Button with multiple states - Are we using Quiver to handle wallet state? - Used in the Yeeter for wallet connection and for one of the transactions - Quiver can be used in the Summon Rage App - Do we have a list of all the input states for validation? - Validation on blur, change, submit, helper text, etc. ## Hub App Design (Rage) - Worthwhile exploring early on for the component and data fetching practices - Can have same stories as building out Rage apps - Are we doing a shareable nav? - Can take in a nav object and populate items - Naming components: - Thinking about how we want to name macros with the designers to create a shared design language - Will theming be included in v3? - Light and dark mode, but not sure beyond this - Limit to a set amount of things that can change and then we can support a theme object (down the road) - MetaUI may have custom theming - Could this be moved to a boost? - Do we enable user created themes? - Identify design tokens to leave the door open for this - Should our data library hit a lambda that provides what is needed when it's hit? OR should it work on a schedule where it hits services directly - Centralizing around our own endpoint may be necessary but we should aim to stay away from this where possible - Design will need to take a pass at the data being used in this since it'll be difficult to grab - When we get to doing this, these conversations will be helpful and inform the data fetching structure - Start by trying to hit the services and then reach toward lambdas if/when this becomes an issue - Do we want to do a click and reveal style UX so we don't grab all this data at once - How would we sort it? - Security -> UX -> Decentralization - Decentralizing our state is critical - If our getters/setters are semi-centralized at first this could be helpful in other areas - Look at use case -> can we use decentralized tech? if so, use it, if not, use a lambda that anyone can read the data from ## Outputs - Create a backlog with these items - Begin identifying priorities and owners ## Next Steps - [ ] Outline initial tasks to get folks working more intentionally on v3 - [ ] Create initial cards from our outline and notes - [ ] Identify teams (Rage and Sage, for example) - [ ] Identify general data models (starting on Hub) and data fetching - [ ] Design Ops Processes (Storybook, Component Library, Figma) - [ ] Define design -> developer handoff processes - [ ] Identify our core design tokens that will be composed ## Reference - [v2 data catalog](https://hackmd.io/o7cVYOO4SxiZ03afDDufqA) - [redux wrapper of an sdk](https://github.com/superfluid-finance/protocol-monorepo/tree/dev/packages/sdk-redux)