blog.waterlow.work

Ruby, Rails, js, etc...

「Presentational and Container Components」を読んだメモ

はじめに

さいきんちょこちょこReactやReduxをやっているのですが、いつも読んだドキュメントのことを忘れてしまうのでちょこちょこまとめて行こうと思います。
今回はReduxの作者でもある@dan_abramov氏の書いた、Presentational and Container Componentsです。

Presentational and Container Components

  • コンポーネントをPresentationalとContainerに分けると、再利用がやりやすくなる。

presentational コンポーネントの特徴

  • 見た目に関すること
  • presentational/container コンポーネントのどちらも含む。
  • DOM markupを含む。
  • this.props.childrenによる封じ込めを許可する(?)
  • アプリケーションの他の機能に依存がない
  • データの扱いや操作は書かない
  • propsを通じてデータやcallback関数を受け取る
  • まれに自身のstateを含む(?)
  • stateへのアクセスや、lifecycle hook、パフォーマンスの問題がない限り(?)はfunctionalにかく
  • ex) Page, Sidebar, Story, UserInfo, List.

container コンポーネントの特徴

  • どう動くかに関すること
  • presentational/container コンポーネントのどちらも含む。
  • ラップするためのdivを除いて、DOM markupを含まない
  • dataや振る舞いを他のpresentational/containerコンポーネントに提供する。
  • Flux actionを呼んでpresentationalコンポーネントにcallback関数として提供する(?)
  • ステートフルで、データソースとして機能することが多い。
  • 手で書かない。React Reduxのconnect()を使う。
  • ex) UserPage, FollowersSidebar, StoryContainer, FollowedUserList.

このアプローチの利点

  • アプリケーションとUIをよく理解できる
  • 再利用性が上がる
  • デザインだけの微調整ができる
  • layout componentsだけを外出することができる。(?)

どちらのコンポーネントもemit DOM(?)を含まないこと

presentationalコンポーネントだけでアプリケーションを作ろうとするとpropsを渡す煩雑さに気づく。(?) propsを渡して歩くよりcontainerを使う方が良い場合がある。(?)

2つのコンポーネントの差はtechnical(?)なものではなく目的である。

宗教的に2つのコンポーネントを書き分けようとしないこと。 presentationかcontainerかわからなければ、あえて決めなくても良い。