---
# System prepended metadata

title: Component Library Overview (Work in Progress)
tags: [magesmiths, ' v3', ' project management', ' dragons']

---

---
tags: magesmiths, v3, dragons, project management
---

# Component Library Overview (Work in Progress)

[Pattern Library Figma](https://www.figma.com/file/R1a1bwODnzCHHHw0EJALAU/DAOhaus-v3-Pattern-Library-(In-Progress))

[Component Library Spec](https://github.com/HausDAO/daohaus-monorepo/wiki/Component-Library-Specification)

## Goals

- Alignment between designers and developers who are working together to build and maintain our design system and component library
- The *Design System* is the overall system we have in place where we have a shared design language, including:
    - Typography
    - Spacing
    - Colors
    - Philosophy and approach
- A core goal for our Sage *Component Library* package is to provide a cohesive user interface across our core DAOhaus apps that matches our Figma *Pattern Library*
    - We strive to have these completely aligned so that we're all *using components* as our foundational building block
- Increases to our speed, consistency, and efficiency
    - Once our core component library is built (especially with Atoms/Micros) we'll be able to utilize these in our Rages and other experiments, increasing efficiency
    - An additional efficiency boost will be due to the consistency that comes from an alignment between designers and developers -- we'll ideally be using and referencing the same design tokens and components, streamlining handoffs and building

### Sage Component Library Goals

- Component Library is a package in our monorepo that we use to build consistent UI
- Component Library will be open source and installable as an npm package that we maintain
    - We'll publish feature updates, and work openly as we build in public
- As components are added, we leverage [Storybook](https://storybook.js.org/) to create Stories and documentation for each component
    - Prod version of our Sage Storybook will be deployed so that the community (and DAOhaus designers) are able to view and interact with the components
- Emphasis on modularity and composition and the ability to support our DAOhaus needs as well as our growing community of builders

## Process (Rage to Sage)

### Rage

- Identify initial components to start on (looking at the current Pattern Library Figma and the Summoner)
- Start by identifying where we are with the *Pattern Library*

### Sage


## Thoughts on Structure

Our approach of *micro* and *macro* is similar to [Atomic Design methodology](https://atomicdesign.bradfrost.com/chapter-2/) where our micro components are the Atoms and our macro components are molecules that can then be composed into more complex UI patterns, pages, and templates.

The DAOhaus component library is built on top of [Radix UI](https://www.radix-ui.com/) and [Stitches](https://stitches.dev). We leverage the base (unstyled) Radix UI components, and build our design tokens with Stitches.

From there, we work with the *variants* approach that Stitches takes to build our micro components. Our structure may look something like this:

**Radix Core**
- We should consider an *import and export* structure where we import the entirety of Radix into our component library package and then export them in a `radix` folder. The folder contains a single `index.ts` which *exports* all of Radix's components. 
- This pattern allows for us to import *only from the component library* across all of our apps. Instead of needing to import only our DAOhaus components and then import anything else from Radix in each app, we build a structure where we import *everything* from our component library package.
- We're then able to manage our dependencies within the component library package which helps avoid version mismatches across the monorepo
- We then focus on adding our variants and styles to these core components, and we build Stories for them
    - (**Need to test this**) but these should still show up in our Storybook if we use this pattern. In my previous experience using Chakra in this way, Chakra components showed up in Storybook

**Micros (Atoms)**

**Macros (Molecules)**

**Purely Functional**

## Components

This is a starting point for a list of components that we can start adding to the Rage version of the component library. As we align with design, we can move these into the Sage component library package.

## Micros/Atoms

### Inputs

We can create a series of universal Input components. These can be purely stylistic or have a mixture of style and functionality. 

**TODO:** Include an abstracted example of this

If we take a functional, opinionated approach we can abstract some of the form interactions such as surfacing errors and wrapping boilerplate for setting up `react-hook-form` Inputs

Each of these has some potential states we'd want to consider:

- [ ]  Input (Filled, With Label, With Label and Errors, Filled With Errors, Outline, With Label, Outline With Label and Errors, Outline With Errors)
- [ ]  Textarea (Filled, With Label, With Label and Errors, Filled With Errors, Outline, With Label, Outline With Label and Errors, Outline With Errors)
- [ ]  Controlled Input and Textarea
- [ ]  DatePicker (With Errors, With Label, With Label and Errors, With Tooltip, With Tooltip and Errors) possibly via `react-datepicker`
    - Using our own custom DatePicker that wraps `react-datepicker` allows for us to style it, including the Button activating the DatePicker
- [ ]  Select (With Errors, With Tooltip, With Tooltip and Errors)
- [ ]  Checkbox
- [ ]  Radio Button / Switch
- [ ]  Label (For all Inputs)
    - Where do we want the labels to appear? Always above? Do we want this to be flexible? We should consider accessibility as well as inputs without labels aren't accessible for screenreaders
- [ ]  Tip (For all Inputs)
    - Tips display *above* the Label. These are optional.
- [ ]  Error Message (For all Inputs)
    - Where do we want these to display? Below the input?

### Typography

There are a few approaches we can take. One is to define our sizes in the entire system and then utilize these as variants in the specific components, or we can set specific sizes for each type of component such as *Heading* and *Text*.

Since Stitches is *variant based* in its API, we can utilize core styles and then create multiple variants per component, and then compose further from there.

**TODO: add example)**

** TODO: Add variant strategy**

- [ ]  Heading
- [ ]  Text
- [ ]  Link / AppLink / ExternalLink
    - We can utilize different styles based on the purpose of the links (internal/app, or external) and create variants to support this
- [ ]  Markdown
    - Since we utilize Markdown (via `ReactMarkdown`) we may want to apply any of core style considerations to any Markdown we parse and style. For example:
        - h1 through h6, paragraph, span, lists, blockquotes, code, etc.

### Other Micros

- [ ]  Buttons (Primary, Secondary, IconButton, etc)
- [ ]  Loading Spinners/Skeletons/Animations
      - Do we want a standard component for this?
- [ ]  Tooltip
- [ ]  Alert
- [ ]  Badges

## Macros

These are either a combination of Mciros

- [ ] Accordion
    - Renderer inside that'll render the inputs inside
- [ ] Form sections
    - Subform? Double Column?
- [ ] Toasts
- [ ] Connect Wallet
- [ ]  Modals
- [ ]  Cards
- [ ]  Tables (possibly via `React Table`)
    - [ ]  Pagination
- [ ]  Charts

## Patterns, Layouts, Templates, and Views

These are composed from combinations of Micros and Macros to form patterns that we reuse. We can name this something else if it makes more sense. There are several names for similar things (patterns, layouts, templates, views) and we can decide what works best for us.

## Functional Components, Utilities, and Helpers

- [ ]  ParseMarkdown / StyledMarkdown
    - If we want to create a specific component that wraps `ReactMarkdown` and utilizes our styles, we can include this as a utility
- [ ]  Color Palette
    - We can include our brand colors in stitches once defined
    
    ```json
        include json example
    ```
    - We'll want to include tints and shades for our core colors (brand) as well as a palette of grays for our UI.
- [ ]  Design Tokens
    - Add our core design tokens for spacing, margin, padding, etc. if we decide to go this route
- [ ]  Iconography
    - Do we want to use only icons from `react-icons` or do we want to also support custom icons from Figma? 
    - We can take a similar approach to the Radix core components and follow an import/export pattern for icons

## Design Language 

### Spacing, Rhythm, and Hierarchy

We'll want to work with design to establish a shared sense of spacing, rhythm, and hierarchy. Here are things to consider: 

- Vertical Rhythms
    - Distance between vertical elements that are in proximity, such as an Input (Micro) and a Form Accordion Section (Macro)
    - Example: Distance of the Label above an Input to any Helper Tips, Distance of Error Messages from Input, Distance from Input to any action Button
- Hierarchy
    - Which elements do we want to have the most prominence when stacked?

### Design Tokens

## Immediate Next Steps

- Create tickets for all inputs
- Create ticket for Raging on the overall structure
- Create tickets for macros: 
    - Accordion
    - Form Columns
- FormBuilder Rework Rage
    - Identify where things can go wrong?
    - Anticipate problems early on
- What are the names and uses of our patterns?
- As we're making the cards, we can outline our questions and then work with the design team to answer these questions
- Have alignment meetings at the onset
- Let's start naming things and use that as a starting point
- Here's the list of things, what are things we need?
    - Does this make sense?
- Our workflow and system needs to be established -- Sage is symbolic but this makes sense here
- Define from the card, and then ask questions
- Have them point to us in the pattern library, and if it doesn't exist they may need to rework a few things
- Do we want a second board for component library related things?

## Other Thoughts

### Haus Web3UI Package

This could be a more opinionated
- Leverages our component library but contains more opinionated choices

Could wrap data sdk to provide more fully functional macro components, ex:
- Connect wallet
- Proposal list with data fetching