Bulletproof Design System with TypeScript

Transcript

1. Bulletproof Design System with TypeScript Bulletproof Design System with TypeScript takanorip / 2025.05.23
2. 大木尊紀 / takanorip 株式会社カンム - エンジニア・デザイナー UIをエンジニアリングするのが好き。 デジタルを脱出したい。 01
6. 0 デザインシステム概観 1 デザインシステムのルール守られない問題 2 TypeScriptとデザインシステム 3 コンポーネントのProps設計 4 デザイントークンの型定義活用 5 LLMによるドキュメントの自動生成
7. 堅牢なデザインシステム
8. デザインシステムの定義 ちいデザシス本によると… “「デザインシステム」は一般的に、「デザインの再現性を高め、一貫した 製品体験を効率よく表現すること」を目的に導入される「ドキュメントや リソース群のこと」と説明されます。” 大塚 亜周,稲葉 志奈,金森 悠,samemaru,圓山 伊吹,植田 将基,関口 裕,8chari,後藤 拓也,小木曽 槙一,桝田 草一. ち いさくはじめるデザインシステム (p.5). Kindle 版.
9. デザインシステム = ルールセット+ドキュメント+実装
10. デザインシステムが達成したいこと 制約を整えて デザインを再現可能にすること ルールをつくるだけでは再現可能にならない。 ルールが適用されたデザインがルールどおりに実装されることが必要不可欠。
11. デザインシステムとUIライブラリの違い 「らしさの再現」が 組み込まれているかどうか プロダクトらしいデザインを再現できるようになっているかどうか。 ただコンポーネントを寄せ集めただけでは「らしく」ならない。 ボトムアップとトップダウン、両方の視点が必要
12. TOP（意思決定が必要） デザイン原則（らしさを定義したもの） ボイス＆トーン スタイルガイド コンポーネント デザイントークン BOTTOM（現状の整理）
13. 90%くらいのエンジニアは デザインシステムのルールを守らない （デザイナーも守らないことある）
14. B デザインシステムのことをよく理解してな3 B ドキュメントを読んでな3 B 面倒だし適当でいいだろと思ってÂ B etc...
15. 堅牢なデザインシステムを 構築したいなら、
16. 人間の善意に頼るのではなく 仕組みでルールを強制する
17. ルールは守られない前提で 逸脱している箇所を見つけやすくする
18. ドキュメントを更新し続ける
19. TypeScriptと デザインシステム
20. デザインシステム = デザインに制約を加える装置 TypeScript = 実装に制約を加える装置
21. TypeScript（型定義）で デザインシステムの制約を強制する
22. TypeScriptがもたらす4つの効果 6 コンポーネントの自由度を適切にコントロールす@ 6 補完やサジェストを活用す@ 6 コンパイルエラーでルール違反を見つけ@ 6 LLMの出力をサポートする
23. 要素ごとに 具体例を紹介していきます
24. デザイントークンの 型定義活用
25. Style Dictionaryを活用 typescript/es6-declarations で型定義を出力する export const : export const : ; ; ColorBackgroundGray string ColorBackgroundBlue string これを利用してコンポーネントのPropsなどを自動生成できる
26. Branded Typesの活用 SpacingとRadiusなど構造が同一だが混同したくないものを区別できる type extends = & in : type = type extends = extends ? | : export type = export const : < , > { [ ] }; ; < > < , > ; < >; ; Branded T U T key U TokenType DesignToken T T TokenType Branded T DesignTokenSpacing DesignToken DesignTokenSpacing string never string string never SizeSpacingXs 'spacing' 'designToken' 'spacing'
27. Branded Typesの生成 Style Dictionaryの を利用する registerTransform import from => => StyleDictionary ; StyleDictionary. ({ type: , transitive: , name: , : ( , ) {}, : ( ) { }, }); 'style-dictionary' `value` `myTransitiveTransform` registerTransform filter transform true token options token // token.value will be resolved and transformed at this point
28. VSCode拡張をつくる Style Dictionaryで生成した型を活用してVS Code拡張などのツールを 開発すると一石二鳥 参考W V V デザイントークンを自動補完するVS Code拡張機能を開発しまし™ CSS Variables 形式のデザイントークンを補完する VS Code Extension を作 成し生産性を上げる
29. コンポーネントの Props設計
30. 基本方針 Styleの上書きを許容しない CSSを書かせない 中途半端に上書きさせない。 どうしても変更したい場合は別コンポーネントを作る。 className や styles は受け取らない。 Propsでスタイルをコントロールする。
31. ubie-ui/Button
32. StyleをPropsで管理する Chakra UI V2のStyle Propsの考え方を採用。 すべてのCSSに対応する必要はなく、必要があるものだけ対応すれば良い。 // mx = margin x < = > </ > Box mx Test Box "xxs"
33. export const : | = ... => return < = ? : ? : ... > </ > < > ({ mx, props }) { ( style {{ : rightKey (rightKey) , : leftKey (leftKey) , }} { } { } BoxComponent ); }; Box FC PropsWithoutText PropsWithTextBody createSpacingVariableFromKey createSpacingVariableFromKey BoxComponent props children '--padding-right' '0' '--padding-left' '0'
34. CSS VariablesをTemplate Literalで管理する const = : => return export const = ?: => return ? : as ( ) { DesignTokens radius key path ; }; ( ) { { : radius (radius) , } ; }; createRadiusVariableFromKey Radius join radiusVariables Radius createRadiusVariableFromKey CSSProperties key radius `var(--${ . [ ]. . ('-')})` '--radius' '0'
35. as Propの活用 type extends = ?: : & export default function extends = ... : const = as || return ... </ > < . > { ; . ; } . ; < . >({ , , } < >) { ; < { }> : {children} Component ; } BoxProps C React ElementType C React ReactNode React ComponentPropsWithoutRef Box C React ElementType BoxProps C Component rest as children as children rest 'div' 'div' Component BOX
36. JSDocのDocumentation機能を活用 エディタの機能を活用して アップデートを知らせる
37. StyleをPropsで管理する Chakra UI V2のStyle Propsの考え方を採用。 すべてのCSSに対応する必要はなく、必要があるものだけ対応すれば良い。 // mx = margin x < = > </ > Box mx Test Box "xxs"
38. Figmaとの連携
39. Figmaをデザイントークンの Single Source of Truthとして扱う デザイントークンは ビジュアルとセットで管理する コード（JSONなど）をSSoTとして扱う風潮もあるが私は懐疑的。 カラーコードを見て色がわかる人がいないと扱えないのでは？ Figma（デザインツール）からJSONを生成するほうが認知不可低いと考える。
41. GitHub Actions経由でデザイントークンを書き出す できる限り自動化しておくことでデザイナーでも更新できるようにする Figma REST API の Open API Spec が公開されているので、 TypeScriptを活用して処理を実装できる https://github.com/figma/rest-api-spec import type from const = await { GetFileResponse } axios. < >(url); result.data '@figma/rest-api-spec' result get GetFileResponse // This has type GetFileResponse
42. Figma JSON (Design Tokens Format Module) GitHub Actions TypeScript, CSS Style Dictionary
43. Figma Variablesは一工夫 Figma VariablesはエンタープライズプランでないとREST API経由での 値取得ができない。 そのためコンポーネントを経由して取得するなどの工夫が必要になる。
44. Variables Variablesの値を適用したオブジェクトをコンポーネント化 コンポーネントのスタイルからトークンの値を取得
45. 余談：Figma Code Connectには懐疑的 便利な機能であることは間違いないが、Figmaでデザインする段階から Code Connectほど強く実装を意識する必要があるのか、わからない。 Figmaで普通にデザインをつくりLLMを活用して開発する、くらいが ちょうどよいと思っている。
46. LLMによる ドキュメントの 自動生成
47. ドキュメントの死 = デザインシステムの死 ドキュメントが更新されなくなると 誰もデザインシステムを使わなくなる どれだけコンポーネントや便利な仕組みが追加されても ドキュメントが更新されなくなったら終わる。
48. なんでドキュメントが更新されないのか デザインシステムのドキュメントは デザイナーパートとエンジニアパートが 混在しているので運用が難しいから 理想的にはデザインシステム専門の編集者がほしい。 しかし大抵の場合そんな余裕はない。 デザインエンジニアが全部書くことになる。
49. そうだ！LLMだ！ LLMなら 両方の視点から いい感じに ドキュメントを 書くことができそう
50. コメントやJSDocがLLMの役に立つ デフォルト値や用途を記述しておくといい感じにまとめてくれる。 /** * サイズ * */ @default large size?: | | ; 'large' 'medium' 'small'
51. 記述するべき内容とWritingStyleを指示する ドキュメントの構成、各セクションに書く内容、だれの視点で書くのか、 などを指示するためのドキュメントを書く contents.md ## Features コンポーネントの概要を記述。 ## Props 各Propsについての解説を記述。 … 参考：個人的 AI Writing のやりかた
52. コンポーネントと指示書をLLMにわたす ドキュメントを書く対象と指示書を渡す。 普通に間違ったこと書いたりするのでレビューは必須。 @src/components/Button.tsx のドキュメントを書いてください。 FigmaのデザインはこのURL @https://www.figma.com/design/... 執筆スタイルは @rules/writing-rule.md に従ってください。
53. デザインシステムは monorepo 化したほうが良い？ ドキュメント作成における LLM支援を最大化したいなら 1つのリポジトリに集約するべき しかし全てをLLMに学習させることは難しいので 与える情報をコントロールする必要がある。MCP？わからん。
54. まとめ
55. まとめ # デザイントークンの型定義を活G # コンポーネントは自由度を下げつつ必要な
 オプションを用意すh # TypeScriptでType SafeなFigma連È # ドキュメントをメンテナンスし続ける
56. Special thank to 腹筋ローラーの力を信じろ @8845musign
57. ありがとう ございました ありがとう ございました