|
1 | 1 | # Design System Boilerplate
|
2 | 2 |
|
3 |
| -Boilerplate monorepo setup with the design system as an internal package and two example apps using the monorepo. |
| 3 | +Boilerplate monorepo setup with the design system as an internal package and two example apps built with the design system. |
4 | 4 |
|
5 | 5 | ## Design System
|
6 | 6 |
|
7 |
| -A strongly typed opinionated design system based on system ui theme specification and styled system component API. |
| 7 | +A strongly typed opinionated design system based on [System UI Theme Specification](https://system-ui.com/theme/) and [Styled System](https://styled-system.com/) component API for rapid UI development. |
8 | 8 |
|
9 | 9 | ### Principles
|
10 | 10 |
|
11 |
| -- Predefine all your themes. i.e no runtime theme creation. This allows us to statically define themes using css variables and create strongly typed themes. Strong types help with full autocomplete support in component APIs. |
12 |
| -- Token groups are identified and based on theme ui specification. Eg. `colors`, `space`, `fontSizes`, etc. |
| 11 | +The design system follows a set of constraints that allows us to statically compile theme definitions and build flexibile APIs. |
| 12 | + |
| 13 | +- Predefine all your themes. i.e no runtime theme creation. This allows us to statically define themes using css variables and create strongly typed themes. Strong types help with full autocomplete support in component APIs. Eg. |
| 14 | + - `Box` component `backgroundColor` prop autocompletes with available color tokens - `primary`, `secondary`, etc. |
| 15 | + - `Box` component `padding` prop autocompletes with available spacing tokens - `small`, `large`, etc. |
| 16 | + |
| 17 | +- Token groups are identified and based on [System UI Theme Specification](https://system-ui.com/theme/). Eg. `colors`, `space`, `fontSizes`, etc. |
| 18 | + |
13 | 19 | - Keep your token groups flat. Don't nest your tokens within token groups. Eg. `colors.primary` is allowed. `colors.primary.success` is not allowed.
|
| 20 | + |
| 21 | +- All themes should have the same set of tokens. Eg. dark theme cannot have a token that's not available in light theme. |
| 22 | + |
14 | 23 | - Theming is driven using CSS custom properties (variables). This allows all themes to have the same tokens values which makes it easy to switch or server render themes. Eg. `token.colors.primary` has the same css variable across themes and makes it easy to statically define styles instead of defining the styles during runtime based on theme. `background: ${tokens.colors.primary}` instead of `background: ${(prop) => prop.theme.colors.primary}`.
|
15 | 24 |
|
| 25 | +### How does theming work? |
| 26 | + |
| 27 | +- Theme definitions are automatically converted to css variables using the `createTheme` utility. |
| 28 | +- The generated css variables are theme-name scoped in `ThemeProvider`. |
| 29 | + |
| 30 | +``` |
| 31 | +body[data-theme="light"] { |
| 32 | + --theme-colors-primary: blue; |
| 33 | + --theme-colors-secondary: lightblue; |
| 34 | +} |
| 35 | +body[data-theme="dark"] { |
| 36 | + --theme-colors-primary: green; |
| 37 | + --theme-colors-secondary: lightgreen; |
| 38 | +} |
| 39 | +``` |
| 40 | + |
16 | 41 | ### Stack
|
17 | 42 |
|
18 | 43 | - Components are styled using emotion
|
@@ -43,19 +68,6 @@ const Example = () => {
|
43 | 68 | };
|
44 | 69 | ```
|
45 | 70 |
|
46 |
| -How does that work? css variables names are theme name scoped. |
47 |
| - |
48 |
| -``` |
49 |
| -body[data-theme="light"] { |
50 |
| - --theme-colors-primary: blue; |
51 |
| - --theme-colors-secondary: lightblue; |
52 |
| -} |
53 |
| -body[data-theme="dark"] { |
54 |
| - --theme-colors-primary: green; |
55 |
| - --theme-colors-secondary: lightgreen; |
56 |
| -} |
57 |
| -``` |
58 |
| - |
59 | 71 | #### Getting current theme name
|
60 | 72 |
|
61 | 73 | Getting current theme is as simple as querying the DOM attribute. You don't need Context or fancy hooks to provide you the value. Although you do have a hook if you need — `useTheme`.
|
|
0 commit comments