@samitouri / QOS-React-2 / commits / d32f8b5a38

Translate 04-multiple-components.md to Japanese

Kohei TAKATA committed Jun 29, 2015 at 21:11 UTC d32f8b5a3883d5e730b3a3398a080538fa14b1c4
1 file changed +186
docs/docs/04-multiple-components.ja-JP.md new
+186
@@ -0,0 +1,186 @@
1 +---
2 +id: multiple-components
3 +title: 複数のコンポーネント
4 +permalink: multiple-components-ja-JP.html
5 +prev: interactivity-and-dynamic-uis-ja-JP.html
6 +next: reusable-components-ja-JP.html
7 +---
8 +
9 +今まで、データを表示したりユーザの入力をハンドルするための1つのコンポーネントの書き方を見てきました。次に、 Reactの最も面白い特徴であるコンポーザビリティについて見ていきましょう。
10 +
11 +## 動機: 関心の分離
12 +
13 +うまく定義されたインターフェースとともに他のコンポーネントを再利用するモジュールのコンポーネントを構築することによって、関数やクラスを使う場合と同じ利益を得ることができます。特に、アプリの *異なった関心を分離* できるにも関わらず、新しいコンポーネントを単純に構築することで満足する場合には。アプリケーションにカスタムコンポーネントライブラリを構築することによって、あなたがやりたいことに最も合う方法でUIを表現することができます。
14 +
15 +## 構成例
16 +
17 +FacebookのグラフAPIを使って、プロフィール画像とユーザー名を表示する単純なアバターのコンポーネントを作ってみましょう。
18 +
19 +```javascript
20 +var Avatar = React.createClass({
21 + render: function() {
22 + return (
23 + <div>
24 + <ProfilePic username={this.props.username} />
25 + <ProfileLink username={this.props.username} />
26 + </div>
27 + );
28 + }
29 +});
30 +
31 +var ProfilePic = React.createClass({
32 + render: function() {
33 + return (
34 + <img src={'https://graph.facebook.com/' + this.props.username + '/picture'} />
35 + );
36 + }
37 +});
38 +
39 +var ProfileLink = React.createClass({
40 + render: function() {
41 + return (
42 + <a href={'https://www.facebook.com/' + this.props.username}>
43 + {this.props.username}
44 + </a>
45 + );
46 + }
47 +});
48 +
49 +React.render(
50 + <Avatar username="pwh" />,
51 + document.getElementById('example')
52 +);
53 +```
54 +
55 +
56 +## 所有
57 +
58 +上記の例では、 `Avatar` のインスタンスは `ProfilePic` と `ProfileLink` のインスタンスを *所有* しています。Reactでは、 **所有者は、他のコンポーネントの `props` をセットするコンポーネントです。** 正式に言うと、もし `Y` コンポーネントの `render()` メソッドの中に `X` コンポーネントが作られた場合、 `X` は `Y` に所有されていると言います。以前述べたように、コンポーネントはそれ自身の `props` を変化させることはできません。 `props` は常に、所有者が彼らにセットしたものと一貫性があります。このキー要素は一貫性があることを保証するために、UIに反映されます。
59 +
60 +所有者と所有される側の関係と、親子の関係の違いを示すのは重要です。所有者と所有される側の関係はReact独特です。一方で、親子の関係は単純にDOMから分かる、愛すべき関係です。上の例では、 `Avatar` は `div` を所有しますが、 `ProfilePic` と `ProfileLink` インスタンスと、 `div` は `ProfilePic` と `ProfileLink`インスタンスの **親** (しかし、所有者ではありません)です。
61 +
62 +
63 +## 子
64 +
65 +Reactのコンポーネントのインスタンスを作成する時には、以下のように開始タグと終了タグの間に付加的なReactのコンポーネントやJavaScriptの表現を含めることができます。
66 +
67 +```javascript
68 +<Parent><Child /></Parent>
69 +```
70 +
71 +`Parent` は特別な `this.props.children` というプロパティでアクセスすることで、子要素を読み取ることができます。 **`this.props.children` は不透明なデータ構造です。** 操作するには[React.Children utilities](/react/docs/top-level-api.html#react.children)を使用してください。
72 +
73 +
74 +### 子要素の調和
75 +
76 +**調和はReactが新しいレンダリングのパスごとにDOMをアップデートするプロセスです。** 一般的に、子要素はレンダリングされる順序に従って調和します。例えば、2つのレンダリングパスを考えると、以下のそれぞれのマークアップが生成されます。
77 +
78 +```html
79 +// パス1のレンダリング
80 +<Card>
81 + <p>Paragraph 1</p>
82 + <p>Paragraph 2</p>
83 +</Card>
84 +// パス2のレンダリング
85 +<Card>
86 + <p>Paragraph 2</p>
87 +</Card>
88 +```
89 +
90 +直感的には、 `<p>Paragraph 1</p>` が削除されたように思えます。代わりに、Reactは1つ目の子要素のテキストコンテンツを変更し、最後の子要素を削除するという変更を加えることでDOMを調和させます。Reactは子要素の *順序* に従って調和するのです。
91 +
92 +
93 +
94 +### ステートフルな子要素
95 +
96 +多くのコンポーネントにとって、これは大きな処理ではありません。しかし、レンダリングのパスを超えて、 `this.state` にデータを保持しているステートフルなコンポーネントにとっては、これはとても問題になり得ます。
97 +
98 +多くのケースにおいては、以下のように、削除する代わりに要素を隠すことで回避することがあります。
99 +
100 +```html
101 +// パス1のレンダリング
102 +<Card>
103 + <p>Paragraph 1</p>
104 + <p>Paragraph 2</p>
105 +</Card>
106 +// パス2のレンダリング
107 +<Card>
108 + <p style={{'{{'}}display: 'none'}}>Paragraph 1</p>
109 + <p>Paragraph 2</p>
110 +</Card>
111 +```
112 +
113 +
114 +### 動的な子要素
115 +
116 +子要素がシャッフルされているような時（検索結果のように）や、リストの最初に新しいコンポーネントが追加されるような時（ストリームのように）には、状況はさらに複雑になります。そういったケースでは、それぞれの子要素のアイデンティティやstateがレンダリングパスを保持する必要があり、以下のように `key` を認識することでそれぞれの子要素をただ1つに識別できます。
117 +
118 +```javascript
119 + render: function() {
120 + var results = this.props.results;
121 + return (
122 + <ol>
123 + {results.map(function(result) {
124 + return <li key={result.id}>{result.text}</li>;
125 + })}
126 + </ol>
127 + );
128 + }
129 +```
130 +
131 +Reactがキー付けされた子要素を調和させるとき、 `key` と子要素が再び整理される（けんかをする代わりに）か削除されます（再利用される代わりに）。
132 +
133 +`key` は以下のように *常に* 配列の中でコンポーネントに直接提供されるべきで、その配列の中でそれぞれのコンポーネントのHTMLの子要素の入れ物に提供されるべきではありません。
134 +
135 +```javascript
136 +// 間違い！
137 +var ListItemWrapper = React.createClass({
138 + render: function() {
139 + return <li key={this.props.data.id}>{this.props.data.text}</li>;
140 + }
141 +});
142 +var MyComponent = React.createClass({
143 + render: function() {
144 + return (
145 + <ul>
146 + {this.props.results.map(function(result) {
147 + return <ListItemWrapper data={result}/>;
148 + })}
149 + </ul>
150 + );
151 + }
152 +});
153 +
154 +// 正解 :)
155 +var ListItemWrapper = React.createClass({
156 + render: function() {
157 + return <li>{this.props.data.text}</li>;
158 + }
159 +});
160 +var MyComponent = React.createClass({
161 + render: function() {
162 + return (
163 + <ul>
164 + {this.props.results.map(function(result) {
165 + return <ListItemWrapper key={result.id} data={result}/>;
166 + })}
167 + </ul>
168 + );
169 + }
170 +});
171 +```
172 +
173 +Reactのフラグのオブジェクトを渡すことで子要素をキー付けすることもできます。詳細は、[キー付けされたフラグ](create-fragment.html)をご覧ください。
174 +
175 +## データフロー
176 +
177 +Reactの、 `props` を通した所有者から所有されるコンポーネントへのデータフローは今までに記述してきました。これは実際には一方向のデータバインディングです。所有者は所有しているコンポーネントのpropsを、所有者が `props` か `state` に基づいて計算したいくつかの値にバインドします。このプロセスが何度も行われるので、データの変更は彼らが使われるところは自動的にどこでも反映されます。
178 +
179 +## パフォーマンスの注意
180 +
181 +みなさんは所有者の下にたくさんのノードがあるときには、データの変更には多くのコストがかかると考えるでしょう。良いニュースとして、JavaScriptは早く、 `render()` メソッドはとても単純になりやすいので、多くのアプリケーションにおいて、こういったことは非常に早くなります。加えて、ボトルネックとなるものの多くは、JSの実行ではなく、DOMの変更です。Reactは変更の一括処理と検知を使うことによって、それを最適化しています。
182 +
183 +しかし、パフォーマンスについて、よりよい制御を持つことを求める時もあるでしょう。こういったケースで、Reactがサブツリーの処理をスキップすることを求めるなら、 `shouldComponentUpdate()` が単純にfalseを返すようにオーバーライドしてください。更に情報を得たい場合には、[Reactのリファレンス文書](/react/docs/component-specs.html)を読んでください。
184 +
185 +> 注意:
186 +> `shouldComponentUpdate()` がデータが実際に変わった時にfalseを返したならば、ReactはUIを同期的に保つことができません。このメソッドを使う際には、何を行っているか理解してください。そして、顕著なパフォーマンスの問題がある時にだけ、この関数を使ってください。DOMと比較して、JavaScriptが速いことを過小評価しないでください。