Fix textlint errors

src/content/blog/2023/05/03/react-canaries.md

@@ -46,13 +46,13 @@ May 3, 2023 by [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](h
 
 Meta では、`main` ブランチから React をビルドし、毎週特定のピン留めされたコミットに手動で更新することによって、この問題を解決しています。これはまた、過去数年間にわたって React Native リリースが実施してきたアプローチでもあります。React Native のすべての*安定版*リリースは、React リポジトリの `main` ブランチの特定のコミットにピン留めされています。これにより、React Native は重要なバグ修正を取り込むことができ、フレームワークレベルで新しい React 機能を段階的に採用し、グローバルな React のリリース予定に依存しないようにできます。
 
-このワークフローを、他のフレームワークや統合済セットアップでも利用可能にしたいと考えているのです。例えば、これにより、React の*上に作られている*フレームワークが、React 関連の破壊的変更を、それが安定版リリース入る*前に*取り込むことができます。これが特に有用なのは、一部の破壊的変更はフレームワークとの結合部分にのみ影響するものであるからです。これによりフレームワークは semver ルールを破ることなく、そのような破壊的変更を独自にマイナーバージョンを付けてリリースできます。
+このワークフローを、他のフレームワークや統合済セットアップでも利用可能にしたいと考えているのです。例えば、これにより、React の*上に作られている*フレームワークが、React 関連の破壊的変更を、それが安定版リリース入る*前に*取り込むことができます。これが特に有用なのは、一部の破壊的変更はフレームワークとの結合部分にのみ影響するものだからです。これによりフレームワークは semver ルールを破ることなく、そのような破壊的変更を独自にマイナーバージョンを付けてリリースできます。
 
 Canary チャンネルでの継続的リリースにより、より緊密なフィードバックループを実現し、新機能がコミュニティで包括的な検証を確実に受けられるようにすることができます。このワークフローは、JavaScript の標準化委員会である TC39 が[番号付きのステージで変更を処理する方法](https://tc39.es/process-document/)に近いものです。新しい React 機能は、React の安定版でリリースされる前に、React をベースにしたフレームワークにおいて先に利用可能になることがあります。これは、新しい JavaScript 機能が、仕様の公式な一部として批准されるより前に、先にブラウザで利用可能になることと同様です。
 
 ## なぜ Experimental リリースを使わないのか？ {/*why-not-use-experimental-releases-instead*/}
 
-技術的には [Experimental リリース](/community/versioning-policy#canary-channel)を使うことは*可能*ですが、実験的な API は、安定化への道のりの途中でで大幅な変更が行われる（または完全に削除される）ことがあるため、実験的リリースを本番環境で使用することはお勧めしません。Canary リリースにも（どんなリリースでもそうであるように）誤りが含まれることはありますが、今後はこのブログで Canary における破壊的変更を告知する予定です。 Canary は、Meta が社内で実行しているコードに最も近いため、一般的には比較的安定していると考えられます。ただし、バージョンを固定して、ピン留めされたコミットを変更する際には手作業で GitHub のコミットログを確認する必要があります。
+技術的には [Experimental リリース](/community/versioning-policy#canary-channel)を使うことは*可能*ですが、実験的な API は、安定化への道のりの途中でで大幅な変更が行われる（または完全に削除される）ことがあるため、実験的リリースを本番環境で使用することはお勧めしません。Canary リリースにも（どんなリリースでもそうであるように）誤りが含まれることはありますが、今後はこのブログで Canary における破壊的変更を告知する予定です。Canary は、Meta が社内で実行しているコードに最も近いため、一般的には比較的安定していると考えられます。ただし、バージョンを固定して、ピン留めされたコミットを変更する際には手作業で GitHub のコミットログを確認する必要があります。
 
 **React を統合済セットアップ（フレームワークなど）以外で使用しているほとんどの人々は、Stable リリースを引き続き使用することになると考えています**。ただし、フレームワークを開発している場合は、特定のコミットにピン留めされた React の Canary バージョンをバンドルし、自分のペースで固定バージョンを更新していくことを検討してください。これによる利点は、過去数年間 React Native で行われてきたことと同様に、完成された個々の React 機能やバグ修正をユーザに対して早期に、かつ自身のリリーススケジュールに基づいて提供できるようになることです。デメリットとしては、取り込まれる React のコミットを自身で確認し、リリースに含まれる React の変更に対してユーザに伝えるための追加の責任が生じるということです。
 
@@ -74,7 +74,7 @@ API の文書化についても、Canary に登場する時点で行われる計
 
 [3 月に発表した](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components)ように、React Server Components の規約は確定しており、ユーザ向けの API に関連する大きな破壊的変更はもう起きないと予想しています。しかし、React Server Components のサポートを React の安定版としてリリースすることはまだできません。なぜなら、いくつかの密接に絡み合ったフレームワーク専用の機能（例：[アセットのローディング](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)）にまだ取り組んでおり、そちらでより多くの破壊的変更が発生することが予想されるからです。
 
-これは、React Server Components はフレームワークによって採用される準備が整っていることを意味します。ただし、次のメジャー React リリースまで、フレームワークがそれらを採用する唯一の方法は、ピン止めされた React の Canary 版と併せてリリースすることです。（React の 2 つのコピーをバンドルしてしまうのを避けるため、これを行いたいフレームワークは、 `react` と `react-dom` がフレームワークとともにリリースされたバージョン固定済みの Canary に解決 (resolve) されるよう強制し、それをユーザーに説明する必要があります。例えば Next.js の App Router はこれを行っています。）
+これは、React Server Components はフレームワークによって採用される準備が整っていることを意味します。ただし、次のメジャー React リリースまで、フレームワークがそれらを採用する唯一の方法は、ピン止めされた React の Canary 版と併せてリリースすることです。（React の 2 つのコピーをバンドルしてしまうのを避けるため、これを行いたいフレームワークは、`react` と `react-dom` がフレームワークとともにリリースされたバージョン固定済みの Canary に解決 (resolve) されるよう強制し、それをユーザに説明する必要があります。例えば Next.js の App Router はこれを行っています。）
 
 ## 安定版と Canary 版の両方に対してライブラリをテストする {/*testing-libraries-against-both-stable-and-canary-versions*/}
 

src/content/blog/index.md

@@ -16,7 +16,7 @@ React チームからの公式な更新のお知らせはこのブログに掲
 
 <BlogCard title="React Canary: Meta 外での段階的な新機能導入" date="May 3, 2023" url="/blog/2023/05/03/react-canaries">
 
-従来、React の新機能は Meta 社内で先に利用可能になり、オープンソースでのリリースは後になっていました。 私たちは、Meta 社内での React 使用法と同様に、安定版がリリースされる前に個々の新機能の設計がほぼ確定した段階でそれらを採用できるという選択肢を、React コミュニティに提供したいと考えています。私たちは、新たに公式サポート対象となる Canary リリースチャンネルを導入します。これにより、フレームワークのような統合済セットアップが、個々の React 機能の採用を React のリリーススケジュールから切り離して行えるようになります。
+従来、React の新機能は Meta 社内で先に利用可能になり、オープンソースでのリリースは後になっていました。私たちは、Meta 社内での React 使用法と同様に、安定版がリリースされる前に個々の新機能の設計がほぼ確定した段階でそれらを採用できるという選択肢を、React コミュニティに提供したいと考えています。私たちは、新たに公式サポート対象となる Canary リリースチャンネルを導入します。これにより、フレームワークのような統合済セットアップが、個々の React 機能の採用を React のリリーススケジュールから切り離して行えるようになります。
 
 </BlogCard>
 

src/content/learn/reacting-to-input-with-state.md

@@ -135,7 +135,7 @@ UI を命令的に操作することは、小さなサンプルではうまく
 
 React はこの問題を解決するために作られました。
 
-React では、あなたが UI を直接操作することはありません。つまり、コンポーネントの有効化、無効化、表示、非表示を直接行うことはありません。代わりに、**表示したいものを宣言する**ことで、React が UI を更新する方法を考えてくれるのです。タクシーに乗ったとき、どこで曲がるかを正確に伝えるのではなく、どこに行きたいかを運転手に伝えることを思い浮かべてください。運転手はあなたをそこに連れて行くのが仕事ですし、あなたが考えもしなかった近道も知っているかもしれません！
+React では、あなたが UI を直接操作することはありません。つまり、コンポーネントの有効化、無効化、表示、非表示を直接行うことはありません。代わりに、**表示したいものを宣言する**ことで、React が UI を更新する方法を考えてくれるのです。タクシーに乗ったとき、どこで曲がるかを正確に伝えるのではなく、どこに行きたいかを運転手に伝えることを思い浮かべてください。運転手はあなたをそこに連れていくのが仕事ですし、あなたが考えもしなかった近道も知っているかもしれません！
 
 <Illustration src="/images/docs/illustrations/i_declarative-ui-programming.png" alt="In a car driven by React, a passenger asks to be taken to a specific place on the map. React figures out how to do that." />
 
@@ -161,7 +161,7 @@ React では、あなたが UI を直接操作することはありません。
 * **Success**：フォームの代わりにお礼のメッセージが表示される。
 * **Error**：Typing 状態と同様だがエラーメッセージも表示される。
 
-デザイナのように、ロジックを追加する前に様々な状態の「モックアップ」を作成することをお勧めします。例えば、フォームの表示部分だけのモックを以下に示します。このモックはデフォルト値が `'empty'` の `status`という props によって制御されます。
+デザイナのように、ロジックを追加する前に様々な状態の「モックアップ」を作成することをお勧めします。例えば、フォームの表示部分だけのモックを以下に示します。このモックはデフォルト値が `'empty'` の `status` という props によって制御されます。
 
 <Sandpack>
 
@@ -697,7 +697,7 @@ body { margin: 0; padding: 0; height: 250px; }
 
 </Sandpack>
 
-異なる 2 つの JSX の塊が同じツリーを記述する場合、それらのネスト（最初の `<div>` → 最初の `<img>`）は一致する必要があることに留意してください。そうでなければ、`isActive` を切り替えると、下のツリー全体が再作成され、[state がリセット](/learn/preserving-and-resetting-state)されてしまいます。このため、同じような JSX ツリーが両方のケースで返される場合は、1つの JSX として記述する方が良いでしょう。
+異なる 2 つの JSX の塊が同じツリーを記述する場合、それらのネスト（最初の `<div>` → 最初の `<img>`）は一致する必要があることに留意してください。そうでなければ、`isActive` を切り替えると、下のツリー全体が再作成され、[state がリセット](/learn/preserving-and-resetting-state)されてしまいます。このため、同じような JSX ツリーが両方のケースで返される場合は、1 つの JSX として記述する方が良いでしょう。
 
 </Solution>
 

src/content/learn/updating-arrays-in-state.md

@@ -40,7 +40,7 @@ JavaScript では、配列とは単なるオブジェクトの一種です。[
 * `slice` は配列や配列の一部をコピーします。
 * `splice` は（要素の挿入や削除という）配列の**ミューテーション**を行います。
 
-React では、state 内のオブジェクトや配列を書き換えたくないため、 `slice`（`p` なし！）の方をより頻繁に使用します。[オブジェクトの更新](/learn/updating-objects-in-state)で、ミューテーションとは何で、それがなぜ state で推奨されないかについて説明されています。
+React では、state 内のオブジェクトや配列を書き換えたくないため、`slice`（`p` なし！）の方をより頻繁に使用します。[オブジェクトの更新](/learn/updating-objects-in-state)で、ミューテーションとは何で、それがなぜ state で推奨されないかについて説明されています。
 
 </Pitfall>
 
@@ -198,7 +198,7 @@ export default function List() {
 
 </Sandpack>
 
-何度か "Delete" タンをクリックして動作を確認したら、クリックハンドラを見て見ましょう。
+何度か "Delete" タンをクリックして動作を確認したら、クリックハンドラを見てみましょう。
 
 ```js
 setArtists(
@@ -336,7 +336,7 @@ button { margin: 5px; }
 
 場合によっては、先頭でも終端でもない特定の位置に要素を挿入したいことがあります。これを行うには、`...` 配列スプレッド構文と `slice()` メソッドを使用できます。`slice()` メソッドを使用すると、配列の「スライス」を切り取ることができます。要素を挿入するには、挿入ポイントの前のスライスを展開した配列、新しい要素、元の配列の残りの部分を作成します。
 
-この例では、 "Insert" ボタンは常にインデックス `1` の場所に挿入を行います。
+この例では、"Insert" ボタンは常にインデックス `1` の場所に挿入を行います。
 
 <Sandpack>
 
@@ -774,7 +774,7 @@ updateMyTodos(draft => {
 
 これが可能なのは、Immer から渡される特別な `draft` オブジェクトを書き換えているのであり、*元の* state は書き換えていないためです。同様に、`draft` の内容に対して `push()` や `pop()` などのミューテーション型のメソッドを使用することもできます。
 
-裏側では、Immer は 常に、`draft` に対して行った書き換え操作に基づいて、次の state をゼロから構築します。これにより、state を書き換えてしまう心配をせず、イベントハンドラを非常に簡潔に保つことができます。
+裏側では、Immer は常に、`draft` に対して行った書き換え操作に基づいて、次の state をゼロから構築します。これにより、state を書き換えてしまう心配をせず、イベントハンドラを非常に簡潔に保つことができます。
 
 <Recap>
 

src/content/learn/updating-objects-in-state.md

@@ -611,7 +611,7 @@ let obj = {
 };
 ```
 
-しかし、オブジェクトの振る舞いを考える場合、「ネスト」という考え方は正確ではありません。コードが実行されてしまえば「ネストされた」オブジェクトというものは存在しません。実際には、2 つの異なるオブジェクトを見ているだけです:
+しかし、オブジェクトの振る舞いを考える場合、「ネスト」という考え方は正確ではありません。コードが実行されてしまえば「ネストされた」オブジェクトというものは存在しません。実際には、2 つの異なるオブジェクトを見ているだけです：
 
 ```js
 let obj1 = {
@@ -626,7 +626,7 @@ let obj2 = {
 };
 ```
 
-`obj1` オブジェクトは `obj2` の「内部」にあるのではありません。例えば、`obj3` も `obj1` を「参照する」ことができます:
+`obj1` オブジェクトは `obj2` の「内部」にあるのではありません。例えば、`obj3` も `obj1` を「参照する」ことができます：
 
 ```js
 let obj1 = {
@@ -670,12 +670,12 @@ Immer から渡される `draft` は、[プロキシ (Proxy)](https://developer.
 
 </DeepDive>
 
-Immer を試すには:
+Immer を試すには：
 
 1. `npm install use-immer` を実行し、Immer を依存ライブラリとして追加する
 2. 次に `import { useState } from 'react'` を `import { useImmer } from 'use-immer'` に置き換える
 
-以下は、Immer に変換された上記の例です:
+以下は、Immer に変換された上記の例です：
 
 <Sandpack>
 
@@ -894,7 +894,7 @@ input { margin-left: 5px; margin-bottom: 5px; }
 
 <Solution>
 
-こちらが両方のバグを修正したバージョンです:
+こちらが両方のバグを修正したバージョンです：
 
 <Sandpack>
 

src/content/reference/react/useDebugValue.md

@@ -37,7 +37,7 @@ function useOnlineStatus() {
 #### 引数 {/*parameters*/}
 
 * `value`: React DevTools に表示したい値。任意の型が使えます。
-* **省略可能** `format`: フォーマッタ関数。コンポーネントがインスペクト (inspect, 調査) されると、React DevTools は `value` を引数としてフォーマッタ関数を呼び出し、返されたフォーマット済みの値（任意の型が使えます）を表示します。フォーマッタ関数を指定しない場合、元の `value` 自体が表示されます。
+* **省略可能** `format`: フォーマッタ関数。コンポーネントがインスペクト（inspect, 調査）されると、React DevTools は `value` を引数としてフォーマッタ関数を呼び出し、返されたフォーマット済みの値（任意の型が使えます）を表示します。フォーマッタ関数を指定しない場合、元の `value` 自体が表示されます。
 
 #### 返り値 {/*returns*/}