回答編集履歴
10
テキスト修正
answer
CHANGED
|
@@ -39,10 +39,10 @@
|
|
|
39
39
|
|
|
40
40
|
- [Presentational and Container Components](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0)
|
|
41
41
|
|
|
42
|
-
個人的には、上記に箇条書きで書かれている、 presentational components と container components それぞれの特徴を、満たす条件ととらえてすべてを厳密に守ろうとすると、融通がきかなくなってしまいがち、という所感を持っています。上記の記事は、はじめ2015年に書かれたものですが、その後、冒頭に`Update from 2019` として追記があり、追記の最後に
|
|
42
|
+
個人的には、上記に箇条書きで書かれている、 presentational components と container components それぞれの特徴を、満たす条件ととらえてすべてを厳密に守ろうとすると、融通がきかなくなってしまいがち、という所感を持っています。（実際、上記の記事は、はじめ2015年に書かれたものですが、その後、冒頭に`Update from 2019` として追記があり、追記の最後に
|
|
43
43
|
> This text is left intact for historical reasons but don’t take it too seriously.
|
|
44
44
|
|
|
45
|
-
とDan氏自身が書いてい
|
|
45
|
+
とDan氏自身が書いています。）
|
|
46
46
|
|
|
47
47
|
とはいえ、今でもひとつの目安にはなるので、上記の記事を、ご質問に挙げられているコードに適用してみると、container components の特徴の中には、
|
|
48
48
|
|
9
テキスト修正
answer
CHANGED
|
@@ -72,7 +72,7 @@
|
|
|
72
72
|
|
|
73
73
|
- container なのか (presentationalな、)component なのかの判別に、redux に connectさせるかどうかは関係ない（少なくとも、判別の条件として、最優先されるわけではない。）
|
|
74
74
|
|
|
75
|
-
ということになるわけですが、これを「そんなことを認めたら、収
|
|
75
|
+
ということになるわけですが、これを「そんなことを認めたら、収拾がつかなくなるので認められない」と考えるか、「redux に connectさせるかどうかに縛られるよりも、 containerは大きな容れ物で、 component は containerに詰められる部品と考えたほうが、開発作業上のメリットが大きい」という考えを採用するかは、プロジェクトによって違っていました。
|
|
76
76
|
|
|
77
77
|
最後の考え方を採用すると、 `components/header/NavIcon.js` を redux に connect させたものを export してよいことになるので、以下のようにも書いてよいことになります。
|
|
78
78
|
|
8
テキスト修正
answer
CHANGED
|
@@ -42,7 +42,7 @@
|
|
|
42
42
|
個人的には、上記に箇条書きで書かれている、 presentational components と container components それぞれの特徴を、満たす条件ととらえてすべてを厳密に守ろうとすると、融通がきかなくなってしまいがち、という所感を持っています。上記の記事は、はじめ2015年に書かれたものですが、その後、冒頭に`Update from 2019` として追記があり、追記の最後に
|
|
43
43
|
> This text is left intact for historical reasons but don’t take it too seriously.
|
|
44
44
|
|
|
45
|
-
とDan氏自身が書いています。
|
|
45
|
+
とDan氏自身が書いていることから、「厳密に守ろうとすると、融通がきかなくなってしまいがち」という所感も間違いではなかったかなという印象です。
|
|
46
46
|
|
|
47
47
|
とはいえ、今でもひとつの目安にはなるので、上記の記事を、ご質問に挙げられているコードに適用してみると、container components の特徴の中には、
|
|
48
48
|
|
7
テキスト修正
answer
CHANGED
|
@@ -39,10 +39,13 @@
|
|
|
39
39
|
|
|
40
40
|
- [Presentational and Container Components](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0)
|
|
41
41
|
|
|
42
|
-
個人的には、上記に箇条書きで書かれている、 presentational components と container components それぞれの特徴を、満たす条件ととらえてすべてを厳密に守ろうとすると、融通がきかなくなってしまいがち、という所感を持っています。
|
|
42
|
+
個人的には、上記に箇条書きで書かれている、 presentational components と container components それぞれの特徴を、満たす条件ととらえてすべてを厳密に守ろうとすると、融通がきかなくなってしまいがち、という所感を持っています。上記の記事は、はじめ2015年に書かれたものですが、その後、冒頭に`Update from 2019` として追記があり、追記の最後に
|
|
43
|
+
> This text is left intact for historical reasons but don’t take it too seriously.
|
|
43
44
|
|
|
44
|
-
|
|
45
|
+
とDan氏自身が書いています。
|
|
45
46
|
|
|
47
|
+
とはいえ、今でもひとつの目安にはなるので、上記の記事を、ご質問に挙げられているコードに適用してみると、container components の特徴の中には、
|
|
48
|
+
|
|
46
49
|
- May contain both presentational and container components inside but usually don’t have any DOM markup of their own except for some wrapping divs, and never have any styles.
|
|
47
50
|
|
|
48
51
|
というものがありますが、これに沿うと、このご質問にある `<Header />` も `<NavIcon />` を含んでいるので、containerコンポーネントである、と言えなくもないです。
|
6
テキスト修正
answer
CHANGED
|
@@ -57,7 +57,7 @@
|
|
|
57
57
|
|
|
58
58
|
Header, About, Top, MyPage, Login, Signup
|
|
59
59
|
|
|
60
|
-
は、 container とする。
|
|
60
|
+
は、 container とする。これの根拠となるのは、「App から直接 import されるものは、ざっくり言って、大きな部品と考えて差し支えないから」という考え方です。
|
|
61
61
|
|
|
62
62
|
- 上記 6 個のcontainerコンポーネントから import されるコンポーネントで、少なくない数の部品的なコンポーネントをimport して、ひとつのまとまった外観と機能を提供するものも containerコンポーネントとする。
|
|
63
63
|
|
5
テキスト修正
answer
CHANGED
|
@@ -67,7 +67,7 @@
|
|
|
67
67
|
|
|
68
68
|
特に、上記のリストの最後の考え方を採用してしまうと、
|
|
69
69
|
|
|
70
|
-
- container なのか (presentationalな、)component なのかの判別に、redux に connectさせるかどうかは関係ない（少なくとも、判
|
|
70
|
+
- container なのか (presentationalな、)component なのかの判別に、redux に connectさせるかどうかは関係ない（少なくとも、判別の条件として、最優先されるわけではない。）
|
|
71
71
|
|
|
72
72
|
ということになるわけですが、これを「そんなことを認めたら、収集がつかなくなるので認められない」と考えるか、「redux に connectさせるかどうかに縛られるよりも、 containerは大きな容れ物で、 component は containerに詰められる部品と考えたほうが、開発作業上のメリットが大きい」という考えを採用するかは、プロジェクトによって違っていました。
|
|
73
73
|
|
4
テキスト修正
answer
CHANGED
|
@@ -49,7 +49,7 @@
|
|
|
49
49
|
|
|
50
50
|
ご質問のコンポーネント構成では、
|
|
51
51
|
|
|
52
|
-
- Redux にconnectさせ
|
|
52
|
+
- `components/` にあるコンポーネント `Xxx` を Redux にconnectさせるソースファイルを `XxxContainer.js` として `containers/` に作成する。
|
|
53
53
|
|
|
54
54
|
というルールにされているのかなと思いました。これはこれでアリな方針でありますが、これ以外の代替案として、
|
|
55
55
|
|
3
テキスト修正
answer
CHANGED
|
@@ -43,7 +43,7 @@
|
|
|
43
43
|
|
|
44
44
|
上記の記事を、ご質問に挙げられているコードに適用してみると、container components の特徴の中には、
|
|
45
45
|
|
|
46
|
-
- May contain both presentational and container components
|
|
46
|
+
- May contain both presentational and container components inside but usually don’t have any DOM markup of their own except for some wrapping divs, and never have any styles.
|
|
47
47
|
|
|
48
48
|
というものがありますが、これに沿うと、このご質問にある `<Header />` も `<NavIcon />` を含んでいるので、containerコンポーネントである、と言えなくもないです。
|
|
49
49
|
|
2
テキスト修正
answer
CHANGED
|
@@ -27,7 +27,7 @@
|
|
|
27
27
|
|
|
28
28
|
小生の過去の react + redux の業務経験ですと、あるプロジェクトでは、
|
|
29
29
|
|
|
30
|
-
- `components/` にはredux にconnect しないコンポーネントを書き、`components/` からimport したコンポーネント
|
|
30
|
+
- `components/` にはredux にconnect しないコンポーネントを書き、`components/` からimport したコンポーネントを redux にconnect させたコンポーネントを `containers/` に入れる。（したがって `components/` の中に、 redux にconnectしたコンポーネントを置くのは禁止）
|
|
31
31
|
|
|
32
32
|
というルールだったところもありますし、
|
|
33
33
|
|
1
テキスト修正
answer
CHANGED
|
@@ -19,4 +19,99 @@
|
|
|
19
19
|
import NavIcon from '../../containers/NavIconContainer'
|
|
20
20
|
```
|
|
21
21
|
|
|
22
|
+
|
|
23
|
+
|
|
24
|
+
### 追記
|
|
25
|
+
|
|
26
|
+
ソースコードのディレクトリ構造に、 `components/` と `containers/` というサブディレクトリーを作ったときに、どのようにコンポーネントを類別して、 `components/` と `containers/` に振り分けていくか？というのはけっこう悩みどころかと思います。
|
|
27
|
+
|
|
28
|
+
小生の過去の react + redux の業務経験ですと、あるプロジェクトでは、
|
|
29
|
+
|
|
30
|
+
- `components/` にはredux にconnect しないコンポーネントを書き、`components/` からimport したコンポーネントクラスを redux にconnect させるたコンポーネントを `containers/` に入れる。（したがって `components/` の中に、 redux にconnectしたコンポーネントを置くのは禁止）
|
|
31
|
+
|
|
32
|
+
というルールだったところもありますし、
|
|
33
|
+
|
|
34
|
+
- `components/` には部品的なものを入れて `containers/` には、部品を配置した（いわば、"大きな" ）コンポーネントを入れておく
|
|
35
|
+
|
|
36
|
+
というルールだったところもあります。
|
|
37
|
+
|
|
38
|
+
`containers/` には、その名のとおり「コンテナ(=容器)であるコンポーネント」を入れておくわけですが、この、"コンテナであるコンポーネント" とそうでないものとの２つに大別するという考え方は、Redux 作者のひとりであるDan Abramovさんの以下の記事が原典かと思います。
|
|
39
|
+
|
|
40
|
+
- [Presentational and Container Components](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0)
|
|
41
|
+
|
|
42
|
+
個人的には、上記に箇条書きで書かれている、 presentational components と container components それぞれの特徴を、満たす条件ととらえてすべてを厳密に守ろうとすると、融通がきかなくなってしまいがち、という所感を持っています。
|
|
43
|
+
|
|
44
|
+
上記の記事を、ご質問に挙げられているコードに適用してみると、container components の特徴の中には、
|
|
45
|
+
|
|
46
|
+
- May contain both presentational and container components** inside but usually don’t have any DOM markup of their own except for some wrapping divs, and never have any styles.
|
|
47
|
+
|
|
48
|
+
というものがありますが、これに沿うと、このご質問にある `<Header />` も `<NavIcon />` を含んでいるので、containerコンポーネントである、と言えなくもないです。
|
|
49
|
+
|
|
50
|
+
ご質問のコンポーネント構成では、
|
|
51
|
+
|
|
52
|
+
- Redux にconnectさせたものがcontainer/ で、それ以外は components/"
|
|
53
|
+
|
|
54
|
+
というルールにされているのかなと思いました。これはこれでアリな方針でありますが、これ以外の代替案として、
|
|
55
|
+
|
|
56
|
+
- まず `App` から import されている以下
|
|
57
|
+
|
|
58
|
+
Header, About, Top, MyPage, Login, Signup
|
|
59
|
+
|
|
60
|
+
は、 container とする。つまり App から直接 import されるものは、大きな部品と考えて差し支えないはずだから、container とする。
|
|
61
|
+
|
|
62
|
+
- 上記 6 個のcontainerコンポーネントから import されるコンポーネントで、少なくない数の部品的なコンポーネントをimport して、ひとつのまとまった外観と機能を提供するものも containerコンポーネントとする。
|
|
63
|
+
|
|
64
|
+
- 上記以外は、 ひとまず、`components/` に入れておき、 その後の修正で、presentational component から container component に "格上げ" してもいいかなと思えたものは、その時点で適宜 `containers/` に移動
|
|
65
|
+
|
|
66
|
+
- `components/` に入れておくものは Redux に connect してはダメというルールを、厳格に守ったほうがいいかはどうかはケースバイケースと考える。
|
|
67
|
+
|
|
68
|
+
特に、上記のリストの最後の考え方を採用してしまうと、
|
|
69
|
+
|
|
70
|
+
- container なのか (presentationalな、)component なのかの判別に、redux に connectさせるかどうかは関係ない（少なくとも、判定の条件として優先順位はそれほど高くない）
|
|
71
|
+
|
|
72
|
+
ということになるわけですが、これを「そんなことを認めたら、収集がつかなくなるので認められない」と考えるか、「redux に connectさせるかどうかに縛られるよりも、 containerは大きな容れ物で、 component は containerに詰められる部品と考えたほうが、開発作業上のメリットが大きい」という考えを採用するかは、プロジェクトによって違っていました。
|
|
73
|
+
|
|
74
|
+
最後の考え方を採用すると、 `components/header/NavIcon.js` を redux に connect させたものを export してよいことになるので、以下のようにも書いてよいことになります。
|
|
75
|
+
|
|
76
|
+
```jsx
|
|
77
|
+
/**
|
|
78
|
+
* components/header/NavIcon.js
|
|
79
|
+
*/
|
|
80
|
+
import React from 'react'
|
|
81
|
+
|
|
82
|
+
・・・
|
|
83
|
+
|
|
84
|
+
class NavIcon extends React.Component {
|
|
85
|
+
・・・
|
|
86
|
+
}
|
|
87
|
+
|
|
88
|
+
// withStylesを適用したNavIconをいったん変数に入れておく。
|
|
89
|
+
const StyledNavIcon = withStyles(styles, { withTheme: true })(NavIcon)
|
|
90
|
+
|
|
91
|
+
// 以下にて、 StyledNavIcon を redux に connectして、これを export default する。
|
|
92
|
+
const mapStateToProps = state => ({
|
|
93
|
+
open: state.NavIconReducer.open,
|
|
94
|
+
})
|
|
95
|
+
|
|
96
|
+
const mapDispatchToProps = dispatch => {
|
|
97
|
+
return{
|
|
98
|
+
handleToggleDrawer: () => dispatch(toggleDrawer())
|
|
99
|
+
}
|
|
100
|
+
}
|
|
101
|
+
|
|
102
|
+
// 上記の StyledNavIcon を redux にconnectする。
|
|
103
|
+
export default connect(mapStateToProps, mapDispatchToProps)(StyledNavIcon)
|
|
104
|
+
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
そして、 `containers/` のほうに移動した、 `header/index.js` にて、
|
|
108
|
+
|
|
109
|
+
```jsx
|
|
110
|
+
import NavIcon from '../../components/header/NavIcon'
|
|
111
|
+
```
|
|
112
|
+
として、redux に connect済みのNavIconを `components/` からimportして使います。
|
|
113
|
+
|
|
114
|
+
もちろん上記の代替案のほうがいいといっているわけではありません。最終的にはメンバーの考えをもとにフロントエンドのリーダーが決定すべき、チームの方針かなと思います。
|
|
115
|
+
|
|
116
|
+
|
|
22
117
|
以上、参考になれば幸いです。
|