Q&A
一点、確認させてください。Dan Abramov氏の次の投稿を読まれた上での質問ということでよろしいでしょうか？ https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0
Reduxには大きくわけて、Presentational ComponentとContainer Componentがあります。
一般的に、Presentationalで書けるところはPresentationalで書き,Reduxと接続する大まかな部分のみをContainerにしようというのをよく聞きます。
しかし、これはなぜでしょうか。
「再利用性を高める」や「その方がシンプルに書ける」などはあまり本質的な理由になっていないように感じます。(あまりちゃんと理解していないので、こここそが本質的な理由なのかもしれません)
例えば極端な考え方として「すべてのコンポーネントをContainer」にする、としたらどんなデメリットが出てくるのでしょうか。
パフォーマンス面、設計面、テスト面などのいろいろな観点からのデメリットをお聞きしたいです。
もしよければその理由の根拠になるページなども教えていただけると嬉しいです。
よろしくお願いします。
【追記】
jun68yktさんに共有していただいた記事を読んでの追記です。
要点をまとめました
分けることのメリット
- 関心の分離ができる
Presentationalとは
- styleする
- データではなくUI情報に関してはstateをもつこともある
- ロジックがないので再利用しやすい
Containerとは
- stylesしない、DOMマークアップは内部で行わない
- ロジックに関心を持つ
- Reduxと接続する
そこで、なんとなく思ったのは、
これらの差異は、「設計するときにこんな感じにわけて考えるとやりやすいよ」というもので、
「Reduxと接続しているか否か」は重要ではないのではないでしょうか。
僕はこれまでContainerとPresentationalの違いを「Reduxと接続しているか否か」の点のみを考えていたので、
「全部『Container(Reduxと接続するもの)』でいいじゃん」という言葉を使ってて疑問の本質から少しずれていました。
つまり、「Reduxと接続しているか否か」のみを除けば、
上述したような「関心の分離」などの恩恵は受けられる気がしました。
そこで、これらを踏まえた疑問として、
- 関心の分離によってPresentationalとContainerをわけるのは設計上有効そう
- じゃあその上で全部Reduxと接続したらどんな弊害があるの？
というものです。
- Reduxと接続した従来のPresentational
- 従来のContainer
の2つに分けて組んでいく感じです。
極端すぎますがatomic designのatomsもすべてReduxとconnectしている感じです。
回答ありがとうございます。 読んでいなかったので読んでみました。 少し長くなるので、質問文の最後に追記しました。よろしくお願いします。
あなたの回答
tips
プレビュー
