diff --git a/.github/workflows/site_lint.yml b/.github/workflows/site_lint.yml index 34ca6d7b8..107b36cb7 100644 --- a/.github/workflows/site_lint.yml +++ b/.github/workflows/site_lint.yml @@ -25,3 +25,6 @@ jobs: - name: Lint codebase run: yarn ci-check + + - name: Textlint (Japanese) + run: yarn textlint \ No newline at end of file diff --git a/src/content/blog/2023/03/16/introducing-react-dev.md b/src/content/blog/2023/03/16/introducing-react-dev.md index a5317c037..7ca78f093 100644 --- a/src/content/blog/2023/03/16/introducing-react-dev.md +++ b/src/content/blog/2023/03/16/introducing-react-dev.md @@ -464,7 +464,7 @@ export default function PackingList() { 各 API ページは少なくとも*リファレンス*と*使用法*の 2 つのセグメントに分かれていることに気付くでしょう。 -[リファレンス](/reference/react/useState#reference)は、API の引数と戻り値をリストアップすることによって、正式な API シグネチャを説明します。簡潔ですが、その API に慣れていない場合は少し抽象的に感じることがあります。API が何をするのかは説明しますが、我々がどのように使用するのかは説明しません。 +[リファレンス](/reference/react/useState#reference)は、API の引数と返り値をリストアップすることによって、正式な API シグネチャを説明します。簡潔ですが、その API に慣れていない場合は少し抽象的に感じることがあります。API が何をするのかは説明しますが、我々がどのように使用するのかは説明しません。 [使用法](/reference/react/useState#usage)では、実際にどのようにこの API を使用するのかを、同僚や友人が説明するような形で示します。これは、**React チームが各 API を使用するために意図した標準的なシナリオ**を示しています。色分けされたスニペット、異なる API を一緒に使用するサンプル、コピーペーストできるレシピも追加しました： diff --git a/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md b/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md index d037d19b2..7038fefdc 100644 --- a/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md +++ b/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md @@ -68,7 +68,7 @@ React Forget の目標は、React アプリがデフォルトでちょうどよ コンパイラのコアは、Babel からほぼ完全に切り離されています。コアコンパイラ API は（大まかには）古い AST から新しい AST への変換（ソース位置データを保持しながら）を行うものです。内部では、カスタムコード表現や変換パイプラインを使用して、低レベルのセマンティック解析を行います。ただし、コンパイラへの主要な公開インターフェースは、Babel やその他のビルドシステムプラグインを通すものです。テストのしやすさのために現在 Babel プラグインを作っており、これはコンパイラを呼び出して各関数の新バージョンを生成し元の関数と入れ替える作業を行う、薄いラッパとなっています。 -過去数ヶ月間でコンパイラをリファクタリングする中で、私たちは条件分岐、ループ、再代入、ミューテーションなどによる複雑性を確実に扱えるよう、コアコンパイルモデルを洗練させることに焦点を当ててきました。ただし JavaScript には、if/else、三項演算子、for、for-in、for-of など、それらの機能を表現する方法がたくさんあります。最初から言語の全てをサポートしようとすると、コアモデルを検証できる時期が遅れてしまったことでしょう。そのかわり、私たちは言語の小さいながらも代表的なサブセットから始めました。`let/const`、`if/else`、`for` ループ、オブジェクト、配列、プリミティブ、関数呼び出し、その他いくつかの機能です。コアモデルに対する自信を得て、内部の抽象化を洗練させながら、サポートされる言語サブセットの範囲を拡大していきました。また、まだサポートしていない構文について明確化し、サポートされていない入力に対しては診断情報をログに記録しつつコンパイルをスキップするようにしました。Meta のコードベースでコンパイラを試すためのユーティリティが存在し、サポートされていない中で最も一般的な機能を見つけ出し、それらを次に優先するよう決めることができるようになっています。言語全体をサポートするまで、段階的にサポート範囲の拡大を続けていく予定です。 +過去数ヶ月間でコンパイラをリファクタリングする中で、私たちは条件分岐、ループ、再代入、ミューテーションなどによる複雑性を確実に扱えるよう、コアコンパイルモデルを洗練させることに焦点を当ててきました。ただし JavaScript には、if/else、三項演算子、for、for-in、for-of など、それらの機能を表現する方法がたくさんあります。最初から言語のすべてをサポートしようとすると、コアモデルを検証できる時期が遅れてしまったことでしょう。そのかわり、私たちは言語の小さいながらも代表的なサブセットから始めました。`let/const`、`if/else`、`for` ループ、オブジェクト、配列、プリミティブ、関数呼び出し、その他いくつかの機能です。コアモデルに対する自信を得て、内部の抽象化を洗練させながら、サポートされる言語サブセットの範囲を拡大していきました。また、まだサポートしていない構文について明確化し、サポートされていない入力に対しては診断情報をログに記録しつつコンパイルをスキップするようにしました。Meta のコードベースでコンパイラを試すためのユーティリティが存在し、サポートされていない中で最も一般的な機能を見つけ出し、それらを次に優先するよう決めることができるようになっています。言語全体をサポートするまで、段階的にサポート範囲の拡大を続けていく予定です。 React コンポーネント内のプレーンな JavaScript をリアクティブにするには、コードが実行していることを正確に理解できる、セマンティクスを深く理解したコンパイラが必要です。このアプローチを取ることで、ドメイン固有言語に制限されるのではなく、JavaScript 言語のすべての表現力を使ってプロダクトコードを記述できる、JavaScript 内リアクティビティシステムを作成しています。 diff --git a/src/content/community/versioning-policy.md b/src/content/community/versioning-policy.md index 880b9fac0..0eead4488 100644 --- a/src/content/community/versioning-policy.md +++ b/src/content/community/versioning-policy.md @@ -4,7 +4,7 @@ title: バージョニングポリシー -React の全ての安定版ビルドは広範なテストに通過しており、セマンティックバージョニング (semver) に従います。また、実験的機能に対する早期フィードバックを促すため、不安定版のリリースチャンネルも提供されています。このページでは、React の各リリースで期待できることについて説明します。 +React のすべての安定版ビルドは広範なテストに通過しており、セマンティックバージョニング (semver) に従います。また、実験的機能に対する早期フィードバックを促すため、不安定版のリリースチャンネルも提供されています。このページでは、React の各リリースで期待できることについて説明します。 diff --git a/src/content/learn/importing-and-exporting-components.md b/src/content/learn/importing-and-exporting-components.md index 3d69ed1e7..b2f816327 100644 --- a/src/content/learn/importing-and-exporting-components.md +++ b/src/content/learn/importing-and-exporting-components.md @@ -149,7 +149,7 @@ JavaScript には値をエクスポートする主な方法が 2 つあります ## 同じファイルから複数のコンポーネントをエクスポート・インポートする {/*exporting-and-importing-multiple-components-from-the-same-file*/} -ギャラリーではなく、`Profile` を 1 つだけを表示したい場合はどうでしょう。`Profile` コンポーネントもエクスポートすればいいのです。しかし、`Gallery.js` にはすでにデフォルトエクスポートがあり、デフォルトエクスポートは 2 つ以上存在できません。デフォルトエクスポートを持つ新しいファイルを作成するか、または `Profile` 用の*名前付き*エクスポートを追加することができます。**1 つのファイルはデフォルトエクスポートを 1 つしか持つことができませんが、名前付きエクスポートはたくさんあっても構いません！** +ギャラリではなく、`Profile` を 1 つだけを表示したい場合はどうでしょう。`Profile` コンポーネントもエクスポートすればいいのです。しかし、`Gallery.js` にはすでにデフォルトエクスポートがあり、デフォルトエクスポートは 2 つ以上存在できません。デフォルトエクスポートを持つ新しいファイルを作成するか、または `Profile` 用の*名前付き*エクスポートを追加することができます。**1 つのファイルはデフォルトエクスポートを 1 つしか持つことができませんが、名前付きエクスポートはたくさんあっても構いません！** diff --git a/src/content/learn/keeping-components-pure.md b/src/content/learn/keeping-components-pure.md index 4a56c4d7b..172dd55eb 100644 --- a/src/content/learn/keeping-components-pure.md +++ b/src/content/learn/keeping-components-pure.md @@ -155,7 +155,7 @@ export default function TeaSet() { React には "Strict Mode" という機能があり、開発中には各コンポーネント関数を 2 回呼び出します。**関数呼び出しを 2 回行うことで、Strict Mode はこれらのルールに反するコンポーネントを見つけるのに役立ちます。** -元の例では "Guest #1"、"Guest #2"、"Guest #3" と表示される代わりに "Guest #2"、"Guest #4"、"Guest #6" と表示されてしまっていましたね。元の関数が純粋でなかったため、2 回呼び出すと壊れていたわけです。修正された純粋なバージョンは、毎回 2 回呼び出されても問題ありません。**純関数は計算をするだけなので、2 回呼び出しても何も変わりません**。`double(2)` を 2 回呼び出しても戻り値が変わることはなく、y = 2x を 2 回解いても y が変わることがないのと全く同じです。入力が同じならば、出力も同じにしてください。常にそうしてください。 +元の例では "Guest #1"、"Guest #2"、"Guest #3" と表示される代わりに "Guest #2"、"Guest #4"、"Guest #6" と表示されてしまっていましたね。元の関数が純粋でなかったため、2 回呼び出すと壊れていたわけです。修正された純粋なバージョンは、毎回 2 回呼び出されても問題ありません。**純関数は計算をするだけなので、2 回呼び出しても何も変わりません**。`double(2)` を 2 回呼び出しても返り値が変わることはなく、y = 2x を 2 回解いても y が変わることがないのと全く同じです。入力が同じならば、出力も同じにしてください。常にそうしてください。 Strict Mode は本番環境では影響を与えないため、ユーザが使うアプリを遅くすることはありません。Strict Mode を有効にするには、ルートコンポーネントを `` でラップします。一部のフレームワークでは、これがデフォルトで行われます。 diff --git a/src/content/learn/lifecycle-of-reactive-effects.md b/src/content/learn/lifecycle-of-reactive-effects.md index 376bc5666..7adf86125 100644 --- a/src/content/learn/lifecycle-of-reactive-effects.md +++ b/src/content/learn/lifecycle-of-reactive-effects.md @@ -23,7 +23,7 @@ title: 'リアクティブなエフェクトのライフサイクル' ## エフェクトのライフサイクル {/*the-lifecycle-of-an-effect*/} -全ての React コンポーネントは同じライフサイクルを持ちます。 +すべての React コンポーネントは同じライフサイクルを持ちます。 - 画面に追加されたとき、コンポーネントは*マウント*されます。 - （大抵はインタラクションに応じて）新しい props や state を受け取ったとき、コンポーネントは*更新*されます。 @@ -552,7 +552,7 @@ button { margin-left: 10px; } ### コンポーネント本体で宣言された変数はすべてリアクティブである {/*all-variables-declared-in-the-component-body-are-reactive*/} -リアクティブな値は、props や state だけではありません。これらの値から導出される値もまた、リアクティブな値となります。props や state が変更されるとコンポーネントは再レンダーされ、導出される値も変化します。これが、コンポーネント本体で宣言された変数で、エフェクトが利用するものは、全てそのエフェクトの依存配列に含まなければならない理由です。 +リアクティブな値は、props や state だけではありません。これらの値から導出される値もまた、リアクティブな値となります。props や state が変更されるとコンポーネントは再レンダーされ、導出される値も変化します。これが、コンポーネント本体で宣言された変数で、エフェクトが利用するものは、すべてそのエフェクトの依存配列に含まなければならない理由です。 ユーザがドロップダウンでチャットサーバを選択できますが、設定でデフォルトサーバを指定することもできるとしましょう。設定の状態を表す state をすでに[コンテクスト](/learn/scaling-up-with-reducer-and-context)に入れていると仮定し、そのコンテクストから `settings` を読み取ります。そして、props から得られる選択されたサーバと、デフォルトサーバに基づいて `serverUrl` を計算します。 diff --git a/src/content/learn/passing-data-deeply-with-context.md b/src/content/learn/passing-data-deeply-with-context.md index 535a23392..313946457 100644 --- a/src/content/learn/passing-data-deeply-with-context.md +++ b/src/content/learn/passing-data-deeply-with-context.md @@ -218,7 +218,7 @@ export default function Heading({ level, children }) { - + 遠くの子にコンテクストを使用 diff --git a/src/content/learn/rendering-lists.md b/src/content/learn/rendering-lists.md index a652287d4..9cedb5309 100644 --- a/src/content/learn/rendering-lists.md +++ b/src/content/learn/rendering-lists.md @@ -30,7 +30,7 @@ title: リストのレンダー ``` -これらのリスト項目は、その中身、すなわちデータのみが異なっています。インターフェースを構築する際にはよく、コメント一覧やプロフィール画像のギャラリーなどのように、異なるデータを使用して同じコンポーネントの複数のインスタンスを表示する必要があります。このような場合、JavaScript のオブジェクトや配列にそのデータを保存し、[`map()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map) や [`filter()`](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Array/filter) などのメソッドを使ってコンポーネントのリストをレンダーすることができます。 +これらのリスト項目は、その中身、すなわちデータのみが異なっています。インターフェースを構築する際にはよく、コメント一覧やプロフィール画像のギャラリなどのように、異なるデータを使用して同じコンポーネントの複数のインスタンスを表示する必要があります。このような場合、JavaScript のオブジェクトや配列にそのデータを保存し、[`map()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map) や [`filter()`](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Array/filter) などのメソッドを使ってコンポーネントのリストをレンダーすることができます。 以下は、配列からアイテムのリストを生成する方法を示す簡単な例です。 diff --git a/src/content/learn/state-a-components-memory.md b/src/content/learn/state-a-components-memory.md index 68f06c1ec..b56a7b923 100644 --- a/src/content/learn/state-a-components-memory.md +++ b/src/content/learn/state-a-components-memory.md @@ -732,7 +732,7 @@ React を使用するためにこのことを理解する必要はありませ state は画面上の個々のコンポーネントインスタンスに対してローカルです。言い換えると、**同じコンポーネントを 2 回レンダーした場合、それぞれのコピーは完全に独立した state を有することになります！** そのうちの 1 つを変更しても、もう 1 つには影響しません。 -この例では、先ほどの `Gallery` コンポーネントが、そのロジックには変更を加えずに 2 回レンダーされています。それぞれのギャラリーの中のボタンをクリックしてみてください。これらの state が独立していることが分かるでしょう。 +この例では、先ほどの `Gallery` コンポーネントが、そのロジックには変更を加えずに 2 回レンダーされています。それぞれのギャラリの中のボタンをクリックしてみてください。これらの state が独立していることが分かるでしょう。 @@ -895,7 +895,7 @@ button { また、`Page` コンポーネントは、`Gallery` の state の値も、そもそも state が存在するかどうかも「知らない」ということにとにも注目してください。props と違い、**state はそれを宣言したコンポーネントに完全にプライベートなものです**。親コンポーネントがそれを変更することはできません。このおかげで、任意のコンポーネントに state を追加したり削除したりしても、他のコンポーネントに影響を与えることはありません。 -両方のギャラリーで state を同期させたい場合はどうすればよいでしょうか？ React での正解は、子コンポーネントから state を*削除*して、それらに最も近い共有の親に追加することです。ここからの数ページでは、1 つのコンポーネント内での state の管理に焦点を当てていますが、[コンポーネント間での state 共有](/learn/sharing-state-between-components)で改めてこのトピックに戻って解説します。 +両方のギャラリで state を同期させたい場合はどうすればよいでしょうか？ React での正解は、子コンポーネントから state を*削除*して、それらに最も近い共有の親に追加することです。ここからの数ページでは、1 つのコンポーネント内での state の管理に焦点を当てていますが、[コンポーネント間での state 共有](/learn/sharing-state-between-components)で改めてこのトピックに戻って解説します。 @@ -913,7 +913,7 @@ button { -#### ギャラリーの完成 {/*complete-the-gallery*/} +#### ギャラリの完成 {/*complete-the-gallery*/} 最後の彫刻が表示されているときに "Next" を押すと、コードがクラッシュします。クラッシュを防ぐためにロジックを修正してください。そのためには、イベントハンドラに追加のロジックを追加するか、操作が不可能な場合はボタンを無効化しましょう。 diff --git a/src/content/reference/react-dom/server/renderToPipeableStream.md b/src/content/reference/react-dom/server/renderToPipeableStream.md index 1e1351e9f..480363c2e 100644 --- a/src/content/reference/react-dom/server/renderToPipeableStream.md +++ b/src/content/reference/react-dom/server/renderToPipeableStream.md @@ -549,7 +549,7 @@ const { pipe } = renderToPipeableStream(, { ストリーミングにより、利用可能になった順でコンテンツをユーザが見えるようになるため、ユーザ体験が向上します。 -しかし、クローラがページを訪れた場合や、ビルド時にページを生成している場合には、コンテンツを徐々に表示するのではなく、全てのコンテンツを最初にロードしてから最終的な HTML 出力を生成したいでしょう。 +しかし、クローラがページを訪れた場合や、ビルド時にページを生成している場合には、コンテンツを徐々に表示するのではなく、すべてのコンテンツを最初にロードしてから最終的な HTML 出力を生成したいでしょう。 `onAllReady` コールバックを用いることで、すべてのコンテンツが読み込まれるまで待機を行うことができます。 diff --git a/src/content/reference/react-dom/server/renderToReadableStream.md b/src/content/reference/react-dom/server/renderToReadableStream.md index 81abd5e43..d3894280f 100644 --- a/src/content/reference/react-dom/server/renderToReadableStream.md +++ b/src/content/reference/react-dom/server/renderToReadableStream.md @@ -561,7 +561,7 @@ async function handler(request) { ストリーミングにより、利用可能になった順でコンテンツをユーザが見えるようになるため、ユーザ体験が向上します。 -しかし、クローラがページを訪れた場合や、ビルド時にページを生成している場合には、コンテンツを徐々に表示するのではなく、全てのコンテンツを最初にロードしてから最終的な HTML 出力を生成したいでしょう。 +しかし、クローラがページを訪れた場合や、ビルド時にページを生成している場合には、コンテンツを徐々に表示するのではなく、すべてのコンテンツを最初にロードしてから最終的な HTML 出力を生成したいでしょう。 Promise である `stream.allReady` を await することで、すべてのコンテンツが読み込まれるまで待機を行うことができます。 diff --git a/src/content/reference/react/Fragment.md b/src/content/reference/react/Fragment.md index 8710253c8..c940fdd8c 100644 --- a/src/content/reference/react/Fragment.md +++ b/src/content/reference/react/Fragment.md @@ -54,7 +54,7 @@ function Post() { } ``` -フラグメントが有用なのは、DOM 要素のような他のコンテナで要素をラップする場合と異なり、フラグメントで要素をグループ化してもレイアウトやスタイルに影響を与えないからです。以下の例をブラウザツールでインスペクト（inspect, 調査）してみると、全ての `

` や `
` DOM ノードがラップされずに兄弟として表示されることがわかります。 +フラグメントが有用なのは、DOM 要素のような他のコンテナで要素をラップする場合と異なり、フラグメントで要素をグループ化してもレイアウトやスタイルに影響を与えないからです。以下の例をブラウザツールでインスペクト（inspect, 調査）してみると、すべての `

` や `
` DOM ノードがラップされずに兄弟として表示されることがわかります。 diff --git a/src/content/reference/react/Suspense.md b/src/content/reference/react/Suspense.md index 1703b8858..5836d040d 100644 --- a/src/content/reference/react/Suspense.md +++ b/src/content/reference/react/Suspense.md @@ -268,7 +268,7 @@ async function getAlbums() { ### コンテンツを一度にまとめて表示する {/*revealing-content-together-at-once*/} -デフォルトでは、サスペンス内の全てのツリーはひとつの単位として扱われます。例えば、以下のコンポーネントのうち*どれかひとつでも*データ待ちでサスペンドしていれば、*すべて*がまとめてローディングインジケータに置き換わります。 +デフォルトでは、サスペンス内のすべてのツリーはひとつの単位として扱われます。例えば、以下のコンポーネントのうち*どれかひとつでも*データ待ちでサスペンドしていれば、*すべて*がまとめてローディングインジケータに置き換わります。 ```js {2-5} }> diff --git a/src/content/reference/react/index.md b/src/content/reference/react/index.md index 5c99ca4cb..3c8f7a93e 100644 --- a/src/content/reference/react/index.md +++ b/src/content/reference/react/index.md @@ -4,7 +4,7 @@ title: "組み込みの React フック" -*フック*を用いると、コンポーネントから様々な React の機能を使えるようになります。組み込みのフックを使うこともできますし、組み合わせて自分だけのものを作ることもできます。このページでは、React に組み込まれた全てのフックを説明します。 +*フック*を用いると、コンポーネントから様々な React の機能を使えるようになります。組み込みのフックを使うこともできますし、組み合わせて自分だけのものを作ることもできます。このページでは、React に組み込まれたすべてのフックを説明します。 @@ -29,7 +29,7 @@ function ImageGallery() { ## コンテクストフック {/*context-hooks*/} -*コンテクスト*を用いると、コンポーネントは props を渡すことなく、[離れた親要素から情報を取得できるようになります](/learn/passing-props-to-a-component)。例えば、アプリの最上位のコンポーネントが、現在の UI テーマをコンポーネントの階層に関係なく全てのコンポーネントに渡すことができます。 +*コンテクスト*を用いると、コンポーネントは props を渡すことなく、[離れた親要素から情報を取得できるようになります](/learn/passing-props-to-a-component)。例えば、アプリの最上位のコンポーネントが、現在の UI テーマをコンポーネントの階層に関係なくすべてのコンポーネントに渡すことができます。 * [`useContext`](/reference/react/useContext) は、コンテクストの値を読み取り、変更を受け取れるようにします。 diff --git a/src/content/reference/react/memo.md b/src/content/reference/react/memo.md index a51c6e4ff..d9af1812e 100644 --- a/src/content/reference/react/memo.md +++ b/src/content/reference/react/memo.md @@ -116,7 +116,7 @@ label { `memo` による最適化は、コンポーネントが全く同一の props で頻繁に再レンダーされ、しかもその再レンダーロジックが高コストである場合にのみ価値があります。コンポーネントが再レンダーされても遅延を感じられない場合、`memo` は不要です。レンダー中に定義されたオブジェクトやプレーンな関数を渡しているなどでコンポーネントに渡される props が*毎回異なる*場合、`memo` は全く無意味であることを覚えておいてください。これが、`memo` と一緒に [`useMemo`](/reference/react/useMemo#skipping-re-rendering-of-components) や [`useCallback`](/reference/react/useCallback#skipping-re-rendering-of-components) がよく必要となる理由です。 -その他のケースでコンポーネントを `memo` でラップすることにメリットはありません。それを行っても重大な害はないため、個別のケースを考えずに、可能な限り全てをメモ化するようにしているチームもあります。このアプローチのデメリットは、コードが読みにくくなることです。また、すべてのメモ化が効果的なわけではありません。例えば、毎回変化する値が 1 つ存在するだけで、コンポーネント全体のメモ化が無意味になってしまうこともあります。 +その他のケースでコンポーネントを `memo` でラップすることにメリットはありません。それを行っても重大な害はないため、個別のケースを考えずに、可能な限りすべてをメモ化するようにしているチームもあります。このアプローチのデメリットは、コードが読みにくくなることです。また、すべてのメモ化が効果的なわけではありません。例えば、毎回変化する値が 1 つ存在するだけで、コンポーネント全体のメモ化が無意味になってしまうこともあります。 **実際には、以下のいくつかの原則に従うことで、多くのメモ化を不要にすることができます**。 diff --git a/src/content/reference/react/useCallback.md b/src/content/reference/react/useCallback.md index 8cae8df5b..2297e1877 100644 --- a/src/content/reference/react/useCallback.md +++ b/src/content/reference/react/useCallback.md @@ -103,7 +103,7 @@ function ProductPage({ productId, referrer, theme }) { `theme` プロパティを切り替えるとアプリが一瞬フリーズすることに気付きましたが、JSX から `` を取り除くと、高速に感じられるのだとしましょう。これは `ShippingForm` コンポーネントの最適化を試みる価値があることを示してます。 -**デフォルトでは、コンポーネントが再レンダーされると、React はその子要素全てを再帰的に再レンダーします**。これが、`ProductPage` が異なる `theme` で再レンダーされると、`ShippingForm` コンポーネント*も*再レンダーされる理由です。再レンダーに多くの計算を必要としないコンポーネントにとっては問題ありません。しかし、再レンダーが遅いことを確認できたなら、[`memo`](/reference/react/memo) でラップすることで、props が前回のレンダー時と同じである場合に `ShippingForm` に再レンダーをスキップするように指示することができます。 +**デフォルトでは、コンポーネントが再レンダーされると、React はその子要素すべてを再帰的に再レンダーします**。これが、`ProductPage` が異なる `theme` で再レンダーされると、`ShippingForm` コンポーネント*も*再レンダーされる理由です。再レンダーに多くの計算を必要としないコンポーネントにとっては問題ありません。しかし、再レンダーが遅いことを確認できたなら、[`memo`](/reference/react/memo) でラップすることで、props が前回のレンダー時と同じである場合に `ShippingForm` に再レンダーをスキップするように指示することができます。 ```js {3,5} import { memo } from 'react'; @@ -223,7 +223,7 @@ function useCallback(fn, dependencies) { - それを [`memo`](/reference/react/memo) でラップされたコンポーネントに props として渡すケース。この場合は、値が変化していない場合には再レンダーをスキップしたいでしょう。メモ化することで、依存値が異なる場合にのみコンポーネントを再レンダーさせることができます。 - あなたが渡している関数が、後で何らかのフックの依存値として使用されるケース。たとえば、他の `useCallback` でラップされた関数がそれに依存している、または [`useEffect`](/reference/react/useEffect) からこの関数に依存しているケースです。 -これらのケース以外では、関数を `useCallback` でラップすることにメリットはありません。それを行っても重大な害はないため、個別のケースを考えずに、可能な限り全てをメモ化するようにしているチームもあります。このアプローチのデメリットは、コードが読みにくくなることです。また、すべてのメモ化が効果的なわけではありません。例えば、毎回変化する値が 1 つ存在するだけで、コンポーネント全体のメモ化が無意味になってしまうこともあります。 +これらのケース以外では、関数を `useCallback` でラップすることにメリットはありません。それを行っても重大な害はないため、個別のケースを考えずに、可能な限りすべてをメモ化するようにしているチームもあります。このアプローチのデメリットは、コードが読みにくくなることです。また、すべてのメモ化が効果的なわけではありません。例えば、毎回変化する値が 1 つ存在するだけで、コンポーネント全体のメモ化が無意味になってしまうこともあります。 `useCallback` は関数の*作成*を防ぐわけではないことに注意してください。あなたは常に関数を作成しています（それは問題ありません！）。しかし、何も変わらない場合、React はそれを無視し、キャッシュされた関数を返します。 @@ -716,7 +716,7 @@ function ChatRoom({ roomId }) { // ... ``` -これには問題があります。[全てのリアクティブな値はエフェクトの依存値として宣言されなければなりません](/learn/lifecycle-of-reactive-effects#react-verifies-that-you-specified-every-reactive-value-as-a-dependency)。しかし、`createOptions` を依存値として宣言すると、あなたのエフェクトがチャットルームに常に再接続することになります。 +これには問題があります。[すべてのリアクティブな値はエフェクトの依存値として宣言されなければなりません](/learn/lifecycle-of-reactive-effects#react-verifies-that-you-specified-every-reactive-value-as-a-dependency)。しかし、`createOptions` を依存値として宣言すると、あなたのエフェクトがチャットルームに常に再接続することになります。 ```js {6} diff --git a/src/content/reference/react/useMemo.md b/src/content/reference/react/useMemo.md index 50d670a6d..8c3c71804 100644 --- a/src/content/reference/react/useMemo.md +++ b/src/content/reference/react/useMemo.md @@ -151,7 +151,7 @@ console.timeEnd('filter array'); - 計算した値を、[`memo`](/reference/react/memo) でラップされたコンポーネントの props に渡す場合。この場合は、値が変化していない場合には再レンダーをスキップしたいでしょう。メモ化することで、依存値が異なる場合にのみコンポーネントを再レンダーさせることができます。 - その値が、後で何らかのフックの依存値として使用されるケース。例えば、別の `useMemo` の計算結果がその値に依存している場合や、[`useEffect`](/reference/react/useEffect) がその値に依存している場合などです。 -これらのケース以外では、計算を `useMemo` でラップすることにメリットはありません。それを行っても重大な害はないため、個別のケースを考えずに、可能な限り全てをメモ化するようにしているチームもあります。このアプローチのデメリットは、コードが読みにくくなるという点です。また、すべてのメモ化が有効であるわけではありません。例えば、毎回変化する値が 1 つ存在するだけで、コンポーネント全体のメモ化が無意味になってしまうこともあります。 +これらのケース以外では、計算を `useMemo` でラップすることにメリットはありません。それを行っても重大な害はないため、個別のケースを考えずに、可能な限りすべてをメモ化するようにしているチームもあります。このアプローチのデメリットは、コードが読みにくくなるという点です。また、すべてのメモ化が有効であるわけではありません。例えば、毎回変化する値が 1 つ存在するだけで、コンポーネント全体のメモ化が無意味になってしまうこともあります。 **実際には、以下のいくつかの原則に従うことで、多くのメモ化を不要にすることができます**。 @@ -565,7 +565,7 @@ export default function TodoList({ todos, tab, theme }) { props である `theme` を変化させると一瞬アプリがフリーズしますが、`` を JSX から削除すると、高速に動作するようになったはずです。すなわち、この `List` コンポーネントには最適化する価値があるということです。 -**通常、あるコンポーネントが再レンダーされたときは、その子コンポーネントも再帰的に全て再レンダーされます**。これが、`TodoList` が異なる `theme` の値で再レンダーされたとき、`List` コンポーネントも*一緒に*再レンダーされる理由です。この動作は、再レンダーにそれほど多くの計算コストを必要としないコンポーネントには適しています。しかし、もし再レンダーが遅いと分かった場合は、`List` コンポーネントを [`memo`](/reference/react/memo) で囲うことで、与えられた props が前回のレンダーと同じである場合に `List` の再レンダーをスキップすることができます。 +**通常、あるコンポーネントが再レンダーされたときは、その子コンポーネントも再帰的にすべて再レンダーされます**。これが、`TodoList` が異なる `theme` の値で再レンダーされたとき、`List` コンポーネントも*一緒に*再レンダーされる理由です。この動作は、再レンダーにそれほど多くの計算コストを必要としないコンポーネントには適しています。しかし、もし再レンダーが遅いと分かった場合は、`List` コンポーネントを [`memo`](/reference/react/memo) で囲うことで、与えられた props が前回のレンダーと同じである場合に `List` の再レンダーをスキップすることができます。 ```js {3,5} import { memo } from 'react'; diff --git a/src/content/reference/react/useReducer.md b/src/content/reference/react/useReducer.md index 946de6db0..271ed2caa 100644 --- a/src/content/reference/react/useReducer.md +++ b/src/content/reference/react/useReducer.md @@ -244,7 +244,7 @@ function reducer(state, action) { } ``` -詳しくは、[state 内のオブジェクトの更新](/learn/updating-objects-in-state)と[state 内の配列の更新](/learn/updating-arrays-in-state)を参照ください。 +詳しくは、[state 内のオブジェクトの更新](/learn/updating-objects-in-state)と [state 内の配列の更新](/learn/updating-arrays-in-state)を参照ください。 diff --git a/src/content/reference/react/useState.md b/src/content/reference/react/useState.md index 67cd605a6..ea6ba96d4 100644 --- a/src/content/reference/react/useState.md +++ b/src/content/reference/react/useState.md @@ -288,7 +288,7 @@ function handleClick() { } ``` -しかし、1 回クリックしたあと、`age` は `45` ではなく `43` になります！ これは、`set` 関数を呼び出しても、既に実行されているコードの `age` state 変数を[更新するわけではない](/learn/state-as-a-snapshot)ためです。そのため、`setAge(age + 1)` の呼び出しは全て `setAge(43)` になります。 +しかし、1 回クリックしたあと、`age` は `45` ではなく `43` になります！ これは、`set` 関数を呼び出しても、既に実行されているコードの `age` state 変数を[更新するわけではない](/learn/state-as-a-snapshot)ためです。そのため、`setAge(age + 1)` の呼び出しはすべて `setAge(43)` になります。 この問題を解消するため、次の state の代わりに、***更新用関数*を `setAge` に渡す**ことができます。 @@ -963,7 +963,7 @@ export default function TodoList() { #### 初期 state を直接渡す {/*passing-the-initial-state-directly*/} -この例では、初期化関数を利用して**いません**。そのため、`createInitialTodos` 関数は、入力フィールドに文字を入力したときなどの全てのレンダーで実行されます。挙動に目に見える違いはありませんが、少し効率が悪くなります。 +この例では、初期化関数を利用して**いません**。そのため、`createInitialTodos` 関数は、入力フィールドに文字を入力したときなどのすべてのレンダーで実行されます。挙動に目に見える違いはありませんが、少し効率が悪くなります。 @@ -1022,7 +1022,7 @@ export default function TodoList() { `key` 属性は、[リストをレンダーする場合](/learn/rendering-lists)によく利用します。しかし、もう 1 つの使い道があります。 -**コンポーネントに異なる `key` を渡すことで、コンポーネントの state をリセットすることができます**。この例では、`version` state 変数を `Form` に `key` として渡しています。"Reset" ボタンをクリックすると、`version` state 変数が変化します。`key` が変化したとき、React は `Form` コンポーネント（と、その全ての子コンポーネント）を一から再生成するため、`Form` の state がリセットされます。 +**コンポーネントに異なる `key` を渡すことで、コンポーネントの state をリセットすることができます**。この例では、`version` state 変数を `Form` に `key` として渡しています。"Reset" ボタンをクリックすると、`version` state 変数が変化します。`key` が変化したとき、React は `Form` コンポーネント（と、そのすべての子コンポーネント）を一から再生成するため、`Form` の state がリセットされます。 詳しくは、[state の保持とリセット](/learn/preserving-and-resetting-state)を参照してください。 @@ -1140,7 +1140,7 @@ button { margin-bottom: 10px; } レンダー中に `set` 関数を呼び出す場合は、`prevCount !== count` のような条件節の中で、`setPrevCount(count)` のような呼び出しが必要なことに注意してください。さもないと、再レンダーのループに陥り、コンポーネントがクラッシュします。また、例のように、*現在レンダーしている*コンポーネントの state のみ更新することができます。レンダー中に*別の*コンポーネントの `set` 関数を呼び出すとエラーになります。最後に、`set` 関数の呼び出しは、[書き換えなしで state を更新](#updating-objects-and-arrays-in-state)する必要があります。これは、[純関数](/learn/keeping-components-pure)の他のルールを破ることができないことを意味します。 -このパターンは理解するのが難しいため、通常は避けるべきです。しかし、エフェクト内で state を更新するよりは良い方法です。レンダー中に `set` 関数を呼び出すと、コンポーネントが `return` 文で終了した直後、子コンポーネントをレンダーする前に再レンダーが行われます。このため、子コンポーネントが 2 回レンダーされずに済みます。コンポーネント関数の残りの部分は引き続き実行されます（結果は破棄されますが）。もし、`set` 関数の呼び出しを含む条件分岐が、全てのフックの呼び出しより下にある場合、早期 `return;` を追加して、再レンダーを早めることができます。 +このパターンは理解するのが難しいため、通常は避けるべきです。しかし、エフェクト内で state を更新するよりは良い方法です。レンダー中に `set` 関数を呼び出すと、コンポーネントが `return` 文で終了した直後、子コンポーネントをレンダーする前に再レンダーが行われます。このため、子コンポーネントが 2 回レンダーされずに済みます。コンポーネント関数の残りの部分は引き続き実行されます（結果は破棄されますが）。もし、`set` 関数の呼び出しを含む条件分岐が、すべてのフックの呼び出しより下にある場合、早期 `return;` を追加して、再レンダーを早めることができます。 --- diff --git a/textlint/prh.yml b/textlint/prh.yml index c833f475e..9342372f9 100644 --- a/textlint/prh.yml +++ b/textlint/prh.yml @@ -87,6 +87,23 @@ rules: pattern: 恐らく prh: 語彙化した副詞はかな書きにします + - expected: すべて + pattern: 全て + prh: 語彙化した副詞はかな書きにします + + - expected: でき$1 + pattern: /出来(る|た[^て]|ます|まし|ませ|ない|ず)/ + prh: 「出来る」は「できる」にします + specs: + - from: 出来ますが + to: できますが + - from: 出来ない + to: できない + - from: 出来たての + to: 出来たての + - from: よい出来の + to: よい出来の + - expected: $1とき$2 pattern: /([うくぐすつぬぶむる]|[なの]|[いん]だ|た)時(は|が|で|を|すら|な|の|に|も|から|まで|、|。|$)/ prh: 形式名詞としての「とき」はかな書きにします @@ -105,7 +122,7 @@ rules: to: 処理が終わったとき。 - expected: $1 - pattern: /(ユーザ|リスナ|エディタ|ハンドラ|トリガ|バンドラ|テスタ|リンタ|フォーマッタ|レンダラ|カウンタ|リデューサ|ブラウザ|アクセシビリティ)ー/ + pattern: /(ユーザ|リスナ|エディタ|ハンドラ|トリガ|バンドラ|テスタ|リンタ|フォーマッタ|レンダラ|カウンタ|リデューサ|ブラウザ|アクセシビリティ|パラメータ|ギャラリ)ー/ prh: 3音以上の技術用語の最後の長音府は原則として省略します - expected: $1レンダー @@ -135,11 +152,18 @@ rules: pattern: 純粋関数 - expected: プレフィックス - pattern: プレフィクス + pattern: (プレフィクス|プリフィックス|プリフィクス) - expected: サフィックス pattern: サフィクス + - expected: リファレンス + pattern: リファランス + + - expected: 返り値 + pattern: 戻り値 + prh: 関数からの return value は返り値とします + - expected: プレーヤ patterns: - プレーヤー