Translate 11-advanced-performance.md to Japanese
Kohei TAKATA committed
Aug 12, 2015 at 19:40 UTC
239eb0fc23c412857e62e3aad284228d59f49c94
1 file changed
+205
docs/docs/11-advanced-performance.ja-JP.md
new
+205
@@ -0,0 +1,205 @@
1
+---
2
+id: advanced-performance
3
+title: 先進的なパフォーマンス
4
+permalink: advanced-performance-ja-JP.html
5
+prev: perf-ja-JP.html
6
+---
7
+
8
+Reactをプロジェクトで使用しようとする際にまず最初に気になるのは、アプリケーションがReactを使用しないバージョンと比べて、同じくらい速くてレスポンシブであるかどうかということです。ステータスの変更毎にレスポンスでコンポーネントのサブツリーの全てを再度レンダリングするという考え方によって、このプロセスがパフォーマンスにネガティブな影響を与えるのではないかと人々は不安に思います。ReactはUIを更新するのに必要な、コストのかかる多くのDOMの操作を最小限にするためのいくつかの賢い技術を使用します。
9
+
10
+## DOMを一致させることを防ぐこと
11
+
12
+ReactはブラウザでレンダリングされるDOMのサブツリーの記述語である *virtual DOM* を使用しています。この2つの表現によってReactは、JavaScriptのオブジェクトの操作よりも遅い、DOMノードを作成したり存在しているDOMノードにアクセスすることを防いでいます。コンポーネントの `props` や `state` が変更された時、Reactは新しいvirtual DOMを構成して、それを古いものと比較することによって、実際のDOMの更新が必要かどうか決定します。それらが同じものでなかった場合にのみ、ReactはDOMを[一致](/react/docs/reconciliation.html)させ、最小限の変更を適用します。
13
+この最上位で、Reactはコンポーネントライフサイクルファンクションである `shouldComponentUpdate` を提供します。これは、再度レンダリングを行うプロセス（virtual DOMの比較と起こり得る最終的なDOMの一致）が始まる前に誘発されます。そして、開発者にこのプロセスの循環を短くすることを可能にします。デフォルトのこの関数の実行時にはReactが更新を行って、以下のように `true` が返ります。
14
+
15
+```javascript
16
+shouldComponentUpdate: function(nextProps, nextState) {
17
+ return true;
18
+}
19
+```
20
+
21
+Reactがとても頻繁にこの関数を呼び出すので、実行が速いものである必要があることを頭に置いておいてください。
22
+
23
+いくつかのチャットのスレッドを持つメッセージングのアプリケーションを持っていると仮定してください。そして、スレッドのうち1つだけが変更されたと考えてください。 `ChatThread` コンポーネントで `shouldComponentUpdate` を実行した際には、Reactは以下のように、他のスレッドのレンダリングステップをスキップできます。
24
+
25
+```javascript
26
+shouldComponentUpdate: function(nextProps, nextState) {
27
+ // TODO: 現在のチャットスレッドが以前のものと
28
+ // 異なっているかどうかをリターンする。
29
+}
30
+```
31
+
32
+つまり、要約すると、ReactはDOMのサブツリーを一致させる必要があるためにコストのかかるDOMの操作を実行するのを避けます。 `shouldComponentUpdate` を使用して、このプロセスを短縮することができます。そして、virtual DOMを比較して、更新すべきDOMだけを更新します。
33
+
34
+## shouldComponentUpdate の実行
35
+
36
+以下はコンポーネントのサブツリーです。1つ1つは `shouldComponentUpdate` が何をリターンするかとvirtual DOMが同じものであるかどうかを示しています。最終的には、円の色が、コンポーネントを一致させる必要があるかどうかを示しています。
37
+
38
+<figure><img src="/react/img/docs/should-component-update.png" /></figure>
39
+
40
+上記の例では、C2の上の `shouldComponentUpdate` が `false` を返しているので、Reactは新しいvirtual DOMを生成する必要はありません。そして、それゆえ、DOMを一致させる必要もありません。C4とC5についても、Reactが `shouldComponentUpdate` を実行する必要がないことに注意してください。
41
+
42
+C1とC3の `shouldComponentUpdate` は `true` を返すので、Reactは葉の部分まで降りてそれらのチェックを行います。C6が `true` を返すので、virtual DOMが同じものではなくなり、DOMを一致させる必要があります。最後の興味深いケースはC8です。このノードについては、Reactはvirtual DOMを計算する必要がありますが、古いものと同じであるため、DOMと一致させる必要はありません。
43
+
44
+ReactがDOMを変化させるのはC6だけであることに注意してください。これは避けられません。C8は、virtual DOMの比較から解放されています。C2のサブツリーとC7も同様です。`shouldComponentUpdate` から解放されているので、virtual DOMの比較を行う必要はありません。
45
+
46
+それでは、私たちはどのように `shouldComponentUpdate` を実行すべきでしょうか？ある文字列の値をただレンダリングするコンポーネントの場合について見てみましょう。
47
+
48
+```javascript
49
+React.createClass({
50
+ propTypes: {
51
+ value: React.PropTypes.string.isRequired
52
+ },
53
+
54
+ render: function() {
55
+ return <div>this.props.value</div>;
56
+ }
57
+});
58
+```
59
+
60
+以下のように簡単に `shouldComponentUpdate` を実行することができます。
61
+
62
+```javascript
63
+shouldComponentUpdate: function(nextProps, nextState) {
64
+ return this.props.value !== nextProps.value;
65
+}
66
+```
67
+
68
+これまでは順調でした。以上のような、単純なpropsやstateの構造を扱うことは簡単です。浅い同一性に基づいて実行したり、コンポーネントに組み込んだりもできます。実際、Reactはそのような実行のためのMixinを既に提供しています。[PureRenderMixin](/react/docs/pure-render-mixin-ja-JP.html)です。
69
+
70
+しかし、コンポーネントのpropsやstateが変更される可能性がある場合はどうでしょうか？propが `bar` のような文字列ではなく、コンポーネント受け取ったものであると考えてみると、 `{ foo: 'bar' }` のような文字列を含んだJavaScriptのオブジェクトになります。
71
+
72
+```javascript
73
+React.createClass({
74
+ propTypes: {
75
+ value: React.PropTypes.object.isRequired
76
+ },
77
+
78
+ render: function() {
79
+ return <div>this.props.value.foo</div>;
80
+ }
81
+});
82
+```
83
+
84
+今までに述べてきた `shouldComponentUpdate` の実行は常に想定した通りに動くとは限りません。
85
+
86
+```javascript
87
+// this.props.value が { foo: 'bar' } であると仮定
88
+// nextProps.value が { foo: 'bar' } であると仮定
89
+// しかし、この参照は this.props.value とは異なります。
90
+this.props.value !== nextProps.value; // true
91
+```
92
+
93
+問題は、 `shouldComponentUpdate` が、propが実際には変化していない場合にも `true` を返すことです。これを修正するために、以下のような代替の実行を行うことができます。
94
+
95
+```javascript
96
+shouldComponentUpdate: function(nextProps, nextState) {
97
+ return this.props.value.foo !== nextProps.value.foo;
98
+}
99
+```
100
+
101
+基本的には、厳密に変更を追跡することを明確にするために、深い比較を行うことになります。パフォーマンスの点では、このアプローチはとてもコストがかかります。これは、それぞれのモデルに対して間違った深い同一性のコードを書いているであろうときには、スケールしません。その最上部では、オブジェクトの参照を注意深く見ていなければ、動作しさえしません。以下のコンポーネントが親から使用されていると考えてください。
102
+
103
+```javascript
104
+React.createClass({
105
+ getInitialState: function() {
106
+ return { value: { foo: 'bar' } };
107
+ },
108
+
109
+ onClick: function() {
110
+ var value = this.state.value;
111
+ value.foo += 'bar'; // アンチパターン！
112
+ this.setState({ value: value });
113
+ },
114
+
115
+ render: function() {
116
+ return (
117
+ <div>
118
+ <InnerComponent value={this.state.value} />
119
+ <a onClick={this.onClick}>Click me</a>
120
+ </div>
121
+ );
122
+ }
123
+});
124
+```
125
+
126
+はじめに、内部のコンポーネントがレンダリングされます。それは、valueというプロパティとして `{ foo: 'bar' }` を保有します。ユーザがアンカーをクリックした際には、親のコンポーネントのstateが `{ value: { foo: 'barbar' } }` にアップデートされるでしょう。そして、新しいvalueのプロパティとして、 `{ foo: 'barbar' }` を受け取る、内部のコンポーネントの再レンダリングのプロセスのトリガーとなります。
127
+
128
+問題は、親と内部のコンポーネントが同じオブジェクトへの参照を共有していることです。オブジェクトが `onClick` 関数の2行目で変更された時には、内部のコンポーネントが保有しているプロパティが変更されるでしょう。そのため、再レンダリングのプロセスが始まった時と、 `shouldComponentUpdate` が呼び出された時には、 `this.props.value.foo` は `nextProps.value.foo` と同じものになるでしょう。そのため、実際は、 `this.props.value` は `nextProps.value` と同じオブジェクトを参照します。
129
+
130
+結果として、プロパティの変更と再レンダリングのプロセスを省略ができなかったので、UIは `'bar'` から `'barbar'` にアップデートされないでしょう。
131
+
132
+## 助けとなるImmutable-js
133
+
134
+[Immutable-js](https://github.com/facebook/immutable-js)はLee Byronによって作成されたJavaScriptのコレクションのライブラリです。Facebookが最近オープンソース化しました。これは、 *構造の共有* を通して、*不変の状態を保ち続ける* コレクションを提供します。以下のプロパティが何を意味するか見ていきましょう。
135
+
136
+* *Immutable*: 一度作成されたら、コレクションは変更できません。
137
+* *Persistent*: 新しいコレクションは以前のコレクションかsetのような変化によってのみ作成されます。元となるコレクションは新しいコレクションが作成された後も使用可能です。
138
+* *Structural Sharing*: 新しいコレクションは元のコレクションとなるべく同じ構造を持って作成されます。パフォーマンスが効率的で許容できるものであるように、コピーを少なくします。新しいコレクションが元のものと同じである場合は、多くの場合元のものがリターンされます。
139
+
140
+不変性によって、変更を追跡するコストが下がります。変更は常に新しいオブジェクトを生むので、オブジェクトの参照が変更されたかどうかを確認しさえすればよいのです。例えば、以下のような一般的なJavaScriptのコードにおいては、
141
+
142
+```javascript
143
+var x = { foo: "bar" };
144
+var y = x;
145
+y.foo = "baz";
146
+x === y; // true
147
+```
148
+
149
+`y` は編集されていますが、`x` と同じオブジェクトを参照しているので、それらの比較は `true` を返します。しかし、以下のコードはimmutable-jsを使用すると以下のように記述されます。
150
+
151
+```javascript
152
+var SomeRecord = Immutable.Record({ foo: null });
153
+var x = new SomeRecord({ foo: 'bar' });
154
+var y = x.set('foo', 'baz');
155
+x === y; // false
156
+```
157
+
158
+このケースでは、 `x` を変更する時に新しい参照が返されているので、 `x` が変更されたことを安全に認識することができます。
159
+
160
+変更を追跡する他の方法は、セッタによるフラグセットを保持することでダーティーチェックを行うことです。このアプローチの問題は、追加のコードを多く書いた場合やクラスの編集をいくつか行った場合でもセッタの使用が強制されることです。代わりに、変化の直前にオブジェクトをディープコピーし、変更が有ろうと無かろうと、その特定のために深い比較を行うことができます。このアプローチの問題は、ディープコピーと深い比較の両方とも、コストの高い操作であることです。
161
+
162
+そのため、不変なデータ構造によって、オブジェクトの変更を追跡するためのコストの低く、冗長ではない方法が提供されます。私たちがすべきなのは `shouldComponentUpdate` を実行することだけです。それゆえ、immutable-jsに提供される抽象化を使用して、propsやstate属性を形作る場合は、 `PureRenderMixin` を使用して、パフォーマンスの向上を行うことができます。
163
+
164
+## Immutable-js と Flux
165
+
166
+[Flux](https://facebook.github.io/flux/)を使用している場合には、immutable-jsを使用して書き直すべきです。[API一覧](https://facebook.github.io/immutable-js/docs/#/)をご覧ください。
167
+
168
+不変のデータ構造を使用したスレッドの例を形作る、ある方法を見ていきましょう。はじめに、形作ろうとしているエンティティのそれぞれに `Record` を定義する必要が有ります。Record はあるフィールドのセットの値を保持している、ただの不変なコンテナです。
169
+
170
+```javascript
171
+var User = Immutable.Record({
172
+ id: undefined,
173
+ name: undefined,
174
+ email: undefined
175
+});
176
+
177
+var Message = Immutable.Record({
178
+ timestamp: new Date(),
179
+ sender: undefined,
180
+ text: ''
181
+});
182
+```
183
+
184
+`Record` 関数はオブジェクトが保有しているフィールドとデフォルトの値を定義するオブジェクトを受け取ります。
185
+
186
+メッセージの *ストア* は以下のように2つのリストを使用して users と messages を追跡し続けることができます。
187
+
188
+```javascript
189
+this.users = Immutable.List();
190
+this.messages = Immutable.List();
191
+```
192
+
193
+それぞれの *ペイロードの* 型を調査することはとても単純で、関数を実行するだけです。例えば、ストアが新しいメッセージを代表するペイロードを調べるときには、新しいレコードを作成し、それを以下のような messages のリストとして適用するだけです。
194
+
195
+```javascript
196
+this.messages = this.messages.push(new Message({
197
+ timestamp: payload.timestamp,
198
+ sender: payload.sender,
199
+ text: payload.text
200
+});
201
+```
202
+
203
+データ構造が不変であることで、push関数の結果を `this.messages` にアサインする必要があることに注意してください。
204
+
205
+Reactの側では、 immutable-js のデータ構造をコンポーネントの state を保持するために使用する場合は、 `PureRenderMixin` をコンポーネントにミックスし、再レンダリングのプロセスを短縮することもできます。
\ No newline at end of file