Tailwind の哲学

STAR UP 社内LT会で発表した内容です。
Tailwind の哲学を理解し、正しいDRY原則を学びましょう！

1. Tailwind CSSの哲学 なぜ今 Tailwind CSS が流行なのか？ Tailwindで学ぶ DDD と DRY原則
2. Tailwindについて話します Tailwind のコード
3. そもそもTailwindを使うメリットは？ - 見た目を素早く記述できる - 変更が安全 （変更が他の箇所に波及しないため） - 古いコードでも分かりやすい （書き方が一通りのため） - 移植性が高い (構造の宣言と見た目の記述が凝集しているため)
4. Tailwindのブレークスルーと 広まった背景
5. Tailwind が登場する以前 構造はHTML、見た目はCSS Tailwind 登場前の関心の分離のベストプラクティス: → HTML と CSS は別のファイルに記述
6. Tailwind CSSが広まった背景 ドメイン駆動設計 (DDD) と強く結びつくプラクティスを 持つ React が登場
7. ドメイン駆動設計 (DDD) とは？ ドメイン: 取り組んでいるビジネス領域のこと ドメイン駆動設計: ビジネス領域の世界とソフトウェアの設計を対応させ、ビジネス領域の拡大をそのまま ソフトウェアに適用できるように設計する開発手法
8. Reactのドメイン分割の例: features ディレクトリ src/
 ├── features/
 │ ├── catalog/ # 商品カタログ
 │ │ ├── components/ 
 │ │ │ └── Catalog.tsx
 │ │ └── hooks/
 │ ├── order/ # 注文管理
 │ │ ├── components/
 │ │ │ └── OrderPage.tsx
 │ │ └── hooks/
 │ └── account/ # 顧客アカウント
 │ ├── components/
 │ │ └── UserList.tsx
 │ └── hooks/
 └── lib/ # 共有ライブラリ
 商品カタログのコンテクスト に関心のある部分 注文管理のコンテクストに関 心のある部分 顧客アカウントのコンテクスト に関心のある部分 DDDについては 「同じ関心を持つものをまとめる」 という認識でとりあえずOK
9. ドメインで分けられていなかった場合 src/
 ├── components/ # (種類) 全てのUIコンポーネントを集約
 │ ├── catalog/
 │ │ └── Catalog.tsx
 │ ├── order/
 │ │ └── OrderPage.tsx
 │ └── account/
 │ └── UserList.tsx
 │
 ├── hooks/ # (種類) 全てのカスタムフックを集約
 │ ├── useProductSearch.ts # 商品カタログ関連のフック
 │ ├── useOrderPlacement.ts # 注文管理関連のフック
 │ └── useAuthentication.ts # 顧客アカウント関連のフック
 │
 └── lib/ # (共有) プロジェクト全体で使う共通ライブラリ
 ファイルの種類ごとに分けるパターン (アーキテクチャによっては現役)
10. Tailwind CSSが広まった背景 ドメイン駆動設計 (DDD) と強く結びつくプラクティスを 持つ React が登場
11. ノーマルＣＳＳ と React の悪い相性 ノーマルCSS では、同じページの構造と見た目が HTML と CSS の２つのファイルに書かれる。 同じ関心をもつ2つのリソースが 低凝集 となっており、DDD のプラクティスに反する。
12. Tailwindが起こしたブレイクスルー 同じ関心をもつ構造と見た目がまとまって 凝集度UP 見た目をコンポーネント (構造) に直接書く Reactなどがコンポーネントを関心の境界で分割する
13. ちなみに - 「構造はHTML、見た目はＣＳＳ」 の原則をやぶるTailwind を好まない開発者は多い - Tailwind がここまで流行っているのは、Vercel (Next.js の開発元) が Tailwind をデファクトスタンダードとして推 し進めてるのも大きい
14. Tailwind と DRY原則
15. DRY原則とは？ Don’t Repeat Yourself 同じコードの繰り返しは避けろ、という意味
16. Tailwind の哲学 Utility-First Utility とは、w-8, flex, font-bold といった、 Tailwind の中核をなす 小さなクラス のこと → 小さなutilityクラスをまず使おう！という意味
17. Tailwind あるある 共通化したい！
18. 重複を無くすオススメの方法 by 公式ドキュメント 1. マルチカーソルを使え！ 2. 繰り返し (list.map() など) を使え！ 3. コンポーネント単位で共通化しろ！ いずれもTailwind自体 の機能ではない…？
19. Tailwind の提供する @apply 機能 スタイルを共通化する方法として @apply などはある しかし、公式ドキュメントでは使用は推奨されていない
20. 実は… 理由 Tailwind ではある程度の重複は許容される！ 安易な共通化には 罠 があるため。
21. つまり この程度の重複はこ のままでOK！
22. Utility-First と DRY原則の矛盾 Tailwindでは、HTML内でのスタイルの繰り返しは必ずしも悪 ではない 真の悪は、 安易な共通化 によって、 異なるコンテクスト内の似ているスタイルが共通化されてしまう ことである。
23. ショートストーリー: 「その共通化、早すぎない？」 ある日、新人のタロウ君がチームに入ってきました。 タロウ君 「あれ？この 『商品購入ボタン』 と 『友達招待ボタン』 って、全 く同じデザインじゃないですか！共通化しましょう！」 そこで、タロウ君は CommonButton コンポーネントを作って 共通化しました。
24. タロウ君の作った CommonButton コンポーネント
25. 1ヶ月後： 「購入ボタンだけローディング状態を表示したい」 → if (type === 'purchase') { ... }
 しかし、時は流れて… 2ヶ月後： 「招待ボタンだけアイコンを付けたい」 → if (type === 'invite') { ... }
 3ヶ月後： 「購入ボタンは在庫切れ時にグレーアウトしたい」 → if (type === 'purchase' && isOutOfStock) { ... }

26. 結果… CommonButton コン ポーネントは大量の責任を 抱え込み、データの流れも 追えない YOU DIED 最終的に保守不能なコード へ…
27. 何がまずかったのか？ ⚠ 一番始めから間違っていた！ あれ？この 『商品購入ボタン』 と 『友達招待ボタン』 って、全 く同じデザインじゃないですか！共通化しましょう！ 商品購入・友達招待という、 異なるコンテクスト のUIを性急にも共通化してしまったこと が間違い
28. そもそも DRY原則 1. 同じコードを繰り返し書くのが面倒になったときに そもそも DRY原則は、 消極的に、心の片隅に置いておけばよい 2. 対象が確かに同じコンテクストに存在し、対象が未来永劫かつ本 質的に同じ関心をもつことを確認してから 3. 共通化しよう！
29. Tailwind で繰り返しが許容されるもう一つの理由 理由: React、Vue のようなコンポーネントベースのＵＩシステム の登場 スタイル単位で共通化しなくても、コンポ―ネント単位で共通化 すればよい！ コンポーネント単位で共通化できない場合は、そもそもコンテ クストが違うので、スタイルを共通化するべきではない
30. 現在のTailwind Tailwind の哲学は、Tailwind v3 までの公式ドキュメントに は記載が充実しているが、 Tailwind v4 の公式ドキュメントではそうした思想に関する記 述がすっかり消えてしまっている。 これからはスタイルの共通化も含めて、様々な書き方を許容して いくという姿勢なのかもしれない
31. 資料 Tailwind v3 公式ドキュメント (https://v3.tailwindcss.com/docs/installation) Tailwind v4 公式ドキュメント (https://tailwindcss.com/docs/installation)
32. ご清聴ありがとうございました！
33. 再利用性における CSS vs Tailwind CSS class にスタイルがまとまっている ため再利用性が高い！ ノーマル ＣＳＳ 構造にスタイルが直書きされている ので再利用性が低い… Tailwind ＣＳＳ → 再利用性の高いノーマルCSSの方が DRY原則にかなって いる？
34. @apply はなぜ非推奨なのか？ 複数のutilityクラスをまとめて再利用する@apply機能 → Utility-First に反し、使いすぎによって結局ノーマル CSSへ戻ってしまうため、限定的な使用が推奨されている