Get Started

The Hoppin Design System is based on:

Styled-System for token-based theming
Styled-Components for CSS-in-JS (see below)

TODO / Discussion

styled-components forward all props to the rendered HTML (using a simple whitelist) resulting in lots of warnings in the console and bad HTML.
- should we use emotion instead?
- same API when using emotion/styled https://emotion.sh/docs/styled
- extra features with babel plugin: https://github.com/emotion-js/emotion/tree/master/packages/babel-plugin-emotion
  - harder to use with create-react-app, as you need to change babel config.
do we want to use something like Reakit for accessibility?

Philosophy

A design system is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications.

Goal to be as useful as Shopify Polaris or Atlasian AtlasKit:

simple onboarding (intro, get started, philosophy, tooling, ...)
tokens (variables)
- token names reflect intention/meaning, not it's visual style (~min 10 in video)
  - hoppinTurquoise => brandPrimary
  - red => danger
components with docs on props, usage, best practices
- When you need a new component, build it locally in the app first, test it, and if it works well, push it upstream into the design-system.
- Flat Component Hierarchies! https://varun.ca/flattening-deep-hierarchies-of-components/

Guiding principles for components:

Keep layout separate
- Design components to only care about itself, not the layout. So say a box should always fill it's container with flex-grow: 1
Respond to context
- e.g. colors not hardcoded, currentColor
- for us: don't use pink, turqoise, etc. use brandPrimary, brandAccent, etc.
Document Assumptions
- for us: use PropTypes or TypeScript, add inline doc comments explaining props.

Setup

Independent Repo, later npm module
All apps depend on design-system module
co-locate component and examples?
- folder structure like:
  - components
    - Button
      - index.js - all the exports
      - Button.js - component
      - Button.md or readme.md (examples for design-system)
- inline jsdoc comments for props, etc

Reading List

Some interesting inputs came form:

Dominic McPhee (Shopify)- Building a Design System in React (Talk at NordicJS 2018)
- Both Philisophy and implemention in react (with fallback to CSS & HTML!)
- Intro to Polaris and it's used here
- When you need a new component, build it locally in the app first, test it, and if it works well, push it upstream into the design-system.
- token names reflect intention/meaning, not it's visual style (~min 10 in video)
  - hoppinTurquoise => brandPrimary
  - red => danger
Glenn Maddern - The Future of Reusable CSS (Talk at ColdFront16)
- Especially from minute 17
- Keep layout separate
  - Design components to only care about itself, not the layout. So say a box should always fill it's container with flex-grow: 1
- Respond to context
  - e.g. colors not hardcoded, currentColor
  - for us: don't use pink, turqoise, etc. use brandPrimary, brandAccent, etc.
- Document Assumptions
  - for us: use PropTypes or TypeScript, add inline doc comments explaining props.
- Open for modification
  - for now, fork into local, test, commit to design-system later?
  - maybe later: Override Pattern as also used by Uber Base Web and described in Gergely Nemeth's article on design systems
- Tokens
  - Sort of invented by Jina Ane
    - Lead Designer for Salesforce Lightening Design System
    - Podcast
    - Slides
    - Theo a library to manage and translate tokens between platforms
  - For token naming issues, the guys at system-ui have some good ideas, discussions
Thinking by Brent Jackson
- on theming
- on styles in react in general which lead to: