Skip to content

Latest commit

 

History

History
53 lines (34 loc) · 3.29 KB

File metadata and controls

53 lines (34 loc) · 3.29 KB

Guideline

コンポーネントディレクトリ構成

本プロジェクトでは、コンポーネントを責務と抽象度に基づいて4つの階層に分類しています。

ui(基礎UI - 最小単位)

それ単体では役割を表現せず、抽象かつ極力汎用的な単位に分解したものを構成するディレクトリです。

  • プリミティブな視覚要素(ボタン、入力フィールド、アイコンなど)
  • 特定の文脈や、役割を持たない
  • 再利用性を最大限に高めた、基礎部品

objects(意味的UI - 役割・構成)

単一、または複数の最小単位の意匠から構成することで、UIに役割を付与することを目的としたディレクトリです。

  • ui ディレクトリの要素を組み合わせて、明確な役割を持つコンポーネントを形成
  • カード、リスト項目、ナビゲーション要素など、特定の用途を持つUI単位
  • ビジネスロジックや、機能的な振る舞いは含まず、UIとしての役割に集中

layouts(構造的UI - 配置・骨格)

個別の意匠や、それらの構成に関心を持たず、それらの配置やサイズの確定を行うことのみを想定したディレクトリです。

  • ページや、セクションの骨格を定義
  • グリッドシステム、レイアウトパターン、配置ルール
  • 子要素の見た目には関与せず、配置と構造のみを担当
  • レイアウトのレスポンシブ対応やスペーシングの制御

features(機能的UI - 振る舞い)

振る舞いを定義するコンポーネント想定のディレクトリです。サイト・アプリケーションの構造に関心を持たず、機能固有の構造に限定して扱うことを想定しています。

  • 特定の機能やビジネスロジックを持つコンポーネント
  • 状態管理、データフェッチング、イベント処理などを含む
  • 機能単位でカプセル化され、独立して動作可能
  • サイト全体の構造からは独立した、機能に特化した構成

設計原則

  • 単一責任の原則: 各ディレクトリの責務を明確に分離し、関心の混在を避ける
  • 抽象度の階層化: (ui → objects → layouts) + features と段階的に具体性を持たせる
  • 依存の方向性: 各UIレイヤーは同一レイヤーに非依存
    • 例:アイコン(UI)、ボタン(UI)、アイコン付きボタン(UI)があった場合、アイコン付きボタンは、アイコンをコンポーネントではなくアセットとして扱い、固有のコンポーネントとして表現
  • 再利用性: 下位層ほど汎用性が高く、上位層ほど特定の文脈に依存する

補足事項

この設計原則は、数百以上のコンポーネントを含む規模のプロジェクトを想定した際に、不透明な依存関係やデッドロックの発生を低減することを重視しています。

プロジェクトの規模によっては、原則における依存性の制約を一定緩和することで、開発コストや実装効率の面でより適切な選択となる場合があります。プロジェクトの実情に応じて、柔軟にご活用ください。