Skip to content

Commit 6bbf280

Browse files
committed
微修正
1 parent a0620fb commit 6bbf280

File tree

1 file changed

+6
-6
lines changed

1 file changed

+6
-6
lines changed

src/content/learn/extracting-state-logic-into-a-reducer.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@ title: state ロジックをリデューサに抽出する
44

55
<Intro>
66

7-
多くのイベントハンドラにまたがって state の更新コードが含まれるコンポーネントは、理解が難しくなりがちです。このような場合、コンポーネントの外部に、*リデューサ (reducer)* と呼ばれる単一の関数を作成し、すべての state 更新ロジックを集約することができます。
7+
多くのイベントハンドラにまたがって state の更新コードが含まれるコンポーネントは、理解が大変になりがちです。このような場合、コンポーネントの外部に、*リデューサ (reducer)* と呼ばれる単一の関数を作成し、すべての state 更新ロジックを集約することができます。
88

99
</Intro>
1010

@@ -381,7 +381,7 @@ function tasksReducer(tasks, action) {
381381

382382
#### なぜリデューサと呼ばれるのか? {/*why-are-reducers-called-this-way*/}
383383

384-
リデューサによりコンポーネント内のコード量を「削減 (recude)」することもできますが、実際にはリデューサは配列で行うことができる [`reduce()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce) という操作にちなんで名付けられています。
384+
リデューサによりコンポーネント内のコード量を「削減 (reduce)」することもできますが、実際にはリデューサは配列で行うことができる [`reduce()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce) という操作にちなんで名付けられています。
385385

386386
`reduce()` 操作とは、配列を受け取り、多くの値を 1 つの値に「まとめる」ことができるものです。
387387

@@ -869,9 +869,9 @@ li {
869869
リデューサにもデメリットがないわけではありません。以下のような様々な点で両者には違いがあります。
870870

871871
- **コードサイズ**:一般に、`useState` を使った方が最初に書くコードは少なくなります。`useReducer` の場合、リデューサ関数とアクションをディスパッチするコードを*両方*書く必要があります。ただし、多くのイベントハンドラが同様の方法で state を変更している場合、`useReducer` によりコードを削減できます。
872-
- **可読性**:シンプルな state 更新の場合は `useState` を読むのは非常に簡単です。しかし、より複雑になると、コンポーネントのコードが肥大化し、見通すことが難しくなります。このような場合、`useReducer` を使うことで、更新ロジックによる「どう更新するのか」と、イベントハンドラによる「何が起きたのか」とを、きれいに分離することができます。
872+
- **可読性**:シンプルな state 更新の場合は `useState` を読むのは非常に簡単です。しかし、より複雑になると、コンポーネントのコードが肥大化し、見通すことが難しくなります。このような場合、`useReducer` を使うことで、更新ロジックによって書かれる「どう更新するのか」と、イベントハンドラに書かれる「何が起きたのか」とを、きれいに分離することができます。
873873
- **デバッグ**`useState` を使っていてバグがある場合、state が*どこで*誤ってセットされたのか、*なぜ*そうなったかを特定するのが難しくなることがあります。`useReducer` を使えば、リデューサにコンソールログを追加することで、すべての state 更新と、それがなぜ起こったか(どの `action` のせいか)を確認できます。それぞれの `action` が正しい場合、リデューサのロジック自体に問題があることが分かります。ただし、`useState` と比べてより多くのコードを調べる必要があります。
874-
- **テスト**:リデューサはコンポーネントに依存しない純関数です。これは、リデューサをエクスポートし、他のものとは別に単体でテストできることを意味します。一般的には、より現実的な環境でコンポーネントをテストするのがベストですが、複雑な state 更新ロジックに対しては、特定の初期 state とアクションに対してリデューサが特定の state を返すことをテストすることが役立ちます。
874+
- **テスト**:リデューサはコンポーネントに依存しない純関数です。これは、リデューサをエクスポートし、他のものとは別に単体でテストできることを意味します。一般的には、より現実的な環境でコンポーネントをテストするのがベストですが、複雑な state 更新ロジックがある場合は、特定の初期 state とアクションに対してリデューサが特定の state を返すことをテストすることが役立ちます。
875875
- **個人の好み**:人によってリデューサが好きだったり、好きではなかったりします。それで構いません。好みの問題です。`useState``useReducer` の間を行ったり来たりすることはいつでも可能です。どちらも同等のものです!
876876

877877
バグが頻繁に発生しておりコンポーネントのコードに構造を導入したい場合に、リデューサを利用することをお勧めします。あらゆるコンポーネントにリデューサを使用する必要はありません。自由に組み合わせてください! 同じコンポーネントで `useState``useReducer` を両方使うことも可能です。
@@ -880,12 +880,12 @@ li {
880880

881881
リデューサを書く際には、以下の 2 つのポイントを心に留めておきましょう。
882882

883-
- **リデューサは純粋である必要があります**[state の更新用関数](/learn/queueing-a-series-of-state-updates)と同様に、リデューサはレンダー中に実行されます!(アクションは次のレンダーまでキューに入れられます。)つまり、リデューサは[純粋である必要があります](/learn/keeping-components-pure)。つまり、同じ入力に対して常に同じ出力になります。リクエストを送信したり、タイムアウトを設定したり、副作用(コンポーネントの外部に影響を与える操作)を実行したりすべきではありません。リデューサは、[オブジェクト](/learn/updating-objects-in-state)[配列](/learn/updating-arrays-in-state)をミューテーションせずに更新する必要があります
883+
- **リデューサは純粋である必要があります**[state の更新用関数](/learn/queueing-a-series-of-state-updates)と同様に、リデューサはレンダー中に実行されます!(アクションは次のレンダーまでキューに入れられます。)つまりリデューサは[純粋でなければならない](/learn/keeping-components-pure)ということです。同じ入力に対して常に同じ出力になります。リクエストを送信したり、タイムアウトを設定したり、副作用(コンポーネントの外部に影響を与える操作)を実行したりすべきではありません。リデューサは、[オブジェクト](/learn/updating-objects-in-state)[配列](/learn/updating-arrays-in-state)をミューテーション(書き換え)せずに更新する必要があります
884884
- **各アクションは、複数データの更新を伴う場合であっても単一のユーザ操作を記述するようにします**。たとえば、リデューサで管理されるフォームに "Reset" ボタンがあり、そのフォームには 5 つのフィールドがある場合、5 つの別々の `set_field` アクションをディスパッチするよりも、1 つの `reset_form` アクションをディスパッチする方が理にかなっています。リデューサの各アクションを記録している場合、そのログは、どんなユーザ操作やレスポンスがどんな順序で発生したかを再構築できるほど明確でなければなりません。これはデバッグに役立ちます!
885885

886886
## Immer を使用した簡潔なリデューサの記述 {/*writing-concise-reducers-with-immer*/}
887887

888-
通常の state における[オブジェクトの更新](/learn/updating-objects-in-state#write-concise-update-logic-with-immer)[配列の更新](/learn/updating-arrays-in-state#write-concise-update-logic-with-immer)と同様に、Immer ライブラリを使用してリデューサをより簡潔にすることができます。ここでは[`useImmerReducer`](https://github.com/immerjs/use-immer#useimmerreducer) を使って、`push` または `arr[i] =` の代入で state をミューテーションできます
888+
通常の state における[オブジェクトの更新](/learn/updating-objects-in-state#write-concise-update-logic-with-immer)[配列の更新](/learn/updating-arrays-in-state#write-concise-update-logic-with-immer)と同様に、Immer ライブラリを使用してリデューサをより簡潔に記述できます。以下の例では[`useImmerReducer`](https://github.com/immerjs/use-immer#useimmerreducer) を使って、`push` または `arr[i] =` という代入を使って state の書き換えを行っています
889889

890890
<Sandpack>
891891

0 commit comments

Comments
 (0)