目次

・[Presentational and Container Componentパターン](#Presentational and Container Componentパターン)
・[Presentational and Container Componentパターンのメリット](#Presentational and Container Componentパターンのメリット)
・[Presentational and Container Componentパターンのデメリット](#Presentational and Container Componentパターンのデメリット)
・まとめ

Presentational and Container Componentパターン

@dan_abramovさんが提唱したコンポーネントの分割方法。

分類すると、 Presentational Component と Container Componentの二つに分類できます。

Presentational Component

見た目を担当するコンポーネント。
DOMやスタイルに対する関心を持ち、コンテンツはpropsによってのみ与えられる。
どのように見えるかに関心があります。

独自のマークアップとスタイルを持つ
多くの場合this.props.childrenとして他に内包される
またアクションやストアに依存しない
なのでデータのロードや変更などのロジックの部分は切り離される
propsとしてデータとコールバックを受け取れる
稀に独自のstateを持つ、それはデータではなくUIの状態として持つ
stateやライフサイクルフック、パフォーマンスの効率化を必要としない限りはfunctional componentとして記述される

Container Component

動作担当するコンポーネント。
データや振る舞いを自身以外へ供給する役割を担う他、状態の参照や管理を行います。
どのように機能するかに関心があります。

通常、ラッピングのdivを除いて独自のDOMマークアップはもたない。スタイルもなし。
Presentational Componentまたその他のコンポーネントにデータと振る舞いを提供する
アクション呼び出しなどをコールバックとしてPresentational Componentに渡す
スタイルなどを持たないという点から、データソースとして機能する傾向があるため、基本的に状態保持と処理を行う
通常、React Reduxのconnect()、RelayのcreateContainer()、Flux Utilsの* Container.create() などの上位コンポーネントを使用して生成される

Presentational and Container Componentパターンのメリット

関心の分離
- 見た目部分とロジック部分を切り離すことで責務を分けることができる
デザイナーとの調整はPresentation Componentのみを使用することで、ロジックから切り離すことができる
- 逆にAPIなどの調整などの場合はContainer Componentのみで対応が可能
  ＊デザイナーとエンジニアで協業しやすくなる

Presentational and Container Componentパターンのデメリット

冗長になる
作成ファイルが増える

まとめ

nuxt/vueでPresentational and Container Componentパターンを試しましたが、利点で書いたようにメリットは大きいなと感じます。
デメリットにある部分はもし開発がデザイナーとエンジニアで切り分けて作業を進めることができる場合はそこまで大きなデメリットには感じないですが、一人で全てをやるなどの場合は作成するファイルが増える分デメリットに感じる部分はあるかなと思いますが、長い目で見たときに運用面などを考えると切り分けておくことの方が大きなメリットと感じます。

参考サイト
https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0