# For Component Library Meeting

## Goals

- For us to understand that the design system is the key contract or protocol between designers and developers.
- Without alignment on this, we cannot have composable UI.
- In organizing our code and designs in the same way, we see gains in UX, DX, and Site Reliablility. Not only that, but we can greatly improve the speed, effeciency and impact of products, while minimizing costs. All of this will free us to work on other meaninful ways to provide value.

## Needs & Questions (nuts and bolts)

Items pertaining to the actual design system/style guide.

**Color**
- Could we move to static colors instead of opactity?
- adds noise if BG is different
- decreases rendering perf
- Colors need labels and a brief description of their function.

**Text
- Descriptors for what role this text plays in

**Inputs**

- Need an example of standard (Mulish) text in an input, or is all input text going to be mono?
- Needs focus state (when it's been clicked on )
- Needs disabled state
- Need an explanation on the scale and measurement illsutration.
- Label text size is different in spec
- Letter spacing is different in Figma than CSS. It recommends 1.8px. I have to use .8px to make it look similar.
- Probably don't need to see every possible input variant with something like required.
- Can button inputs be the same length as the other inputs
- Seems like we have three lengths of input, and I think it would it difficult to stack things.
- I don't think content type should be the main variant and reason for determining input length (ex. address input)
- How would we stack button inputs with inputs in a single column layout?
- Helper text seems a bit hard to read.

**Handling Variants**
- Labelling what the variant is.
- Would be helpful if we organized by state (ex. input 'focused' state) as opposed to additional UI (displaying helper text)
- Could remove redundant elements if the pattern is the same, ex. if all helper text is 11px below

## Workflow
- Pipelines. Would be nice if we can finish one component at a time instead of going wide.
- Probably best to nail global styles first, then move to individual components
- Could we handle variants in a graph sort of way (states along X axis, variants along the Y axis)?
- In my course, it is accepted that designers pull from the system to create their designs. To me, this bottom-up approach makes a lot of sense. How do we get there?
- 2 Checkpoint system.
- In order to say something is ready for dev, dev and designers run through a list and go through the component's design and ensure everything is there.
- Once dev is complete (code review, QA, etc) Designers should audit the UI. With Storybook, Designers now have an interface where they can audit components and make sure they meet spec.

## The Big Question
- Is the tail wagging the dog here? Should final components used in final designs not be derived from the design system instead of deriving the components from a one-off layout design?
- I ask this because I'm noticing that there's a lot of spacing that's like 5.66px or components that work better for Summoner's one-off design (inputs with different lengths etc) than it does for an overall system that is repeatable.
- If yes, how would we move forward?

## Dev Notes on Radix/Styled Components
- Very slow
- Radix has horrible docs
- Radix's docs aren't TS
- It's hard to get things working initially
- Is it easier than building out own? (probably)
- Styled components does allow for a lot of granularity
- However, theme organization will be very invloved.
- If we're down for that extra work, I'm pretty sure there will be some payoff later on.

## Dev Notes on Monorepo
- long delay on monorepo
- Persistant errors in ui tsConfig.json that never go away unless you close the editor window. They reappear shortly after.

Cannot find type definition file for '@nxext/react/client'.
  The file is in the program because:
    Entry point of type library '@nxext/react/client' specified in compilerOptionsts