Reactのコンポーネント設計
Tamtam
Atomic Design
５要素にコンポーネントを分割していくデザイン手法
Atom - UIの最小単位。それ以上機能的に分割できないもの。ボタンとかテキストとか。
Molecule - Atomを組み合わせて作られる要素。検索フォームとか。
Organisms - MoleculesやAtomを組み合わせて作られる要素。ヘッダーとかがイメージしやすい。Moleculeとの違いは単一の機能でなく複数の役割を持つこと
Template - Organismsを組み合わせたもの。いわゆるワイヤーフレーム
Pages - 実際の文言などのデータがTemplateに注ぎ込まれたもの。
Molecule単位のコンポーネントをデザインする時に重要な考え方...原則としてコンポーネントは一つのことに責任を持つべき
Tamtam
- UIとUIロジックは密結合
- UIと業務ロジックは疎結合
- UIロジックと業務ロジックは疎結合
atoms
コンポーネントの最小単位。
ロジックは持たない。
ステートレスなコンポーネント。
システム全体で流用できる。
molecules
atoms、moleculesの複合コンポーネント。
UIロジックを持つことがある。
ステートレスなコンポーネント。
システム全体で流用できる。
organisms
atoms、moleculesの複合コンポーネント。
業務のドメイン情報をDOMに持つことがある。
そのためシステム全体で流用できるとは限らない。
APIとの疎通や業務ロジックを持つことがある。
そのためステートレスとは限らない。
Presentational/Container Componentsの実装方針
organismsの中でもPresentationalComponentsとContainerComponentsはディレクトリも区分けして明確に違うものとして定義しておくのが良いです。
そうすることで修正が必要な場合にどちらのコンポーネントを修正すべきかも明確に判断が付きます。
ただコンポーネントの実装を始める前からPresentational/Container Componentsをどういった構造にすべきか設計することは難易度が非常に高いです。 まずはPresentational Componentsをひたすら実装していき、画面まで実装するのが望ましいです。 その後APIをpagesコンポーネントで繋ぎこみます。 pagesでAPIを発行するとorganismsのPresentational Componentsを辿って末端のatomsコンポーネントまでデータをバケツリレーしていくことになります。 この時にpropsとして受け取ったデータを無加工でそのまま更に末端のコンポーネントに渡す場面が発生するはずです。 その場面でContainer Componentsの実装を検討していくというのが手戻りを少なくできます。
Tamtam
useHugeComponent.tsとしてhooksを切り出す
Tamtam
1~2~3の施策は「ピザを売るというサービスにおける制約」の変更であり、まさにビジネスルール&ロジックがビジネスの発展とともに複雑化していく様子を表しています。
また、この制約はweb注文フォームだけでなく、直接販売によるposレジでも、手書き伝票でも同じルールが必要になることでしょう。ビジネスルール（≒ロジック）がインターフェイスに依存しないことがわかります。分離の3~4の差分でクラスに修正が入らないのは、この依存状態をコードでしっかりと表現できているからです。
Tamtampropsの受け取り方の時に意識する
