Fix style errors in useEffect reference

Author: smikitky

src/content/reference/react/useEffect.md

@@ -114,7 +114,7 @@ function ChatRoom({ roomId }) {
 
 上記の `ChatRoom` コンポーネントがページに追加されると、`serverUrl` と `roomId` の初期値を使ってチャットルームに接続します。`serverUrl` または `roomId` が再レンダーの結果として変更される場合（例えば、ユーザがドロップダウンで別のチャットルームを選択した場合）、あなたの副作用は*以前のルームから切断し、次のルームに接続します*。`ChatRoom` コンポーネントがページから削除されると、あなたの副作用は最後の切断を行います。
 
-**[バグを見つけ出すために](/learn/synchronizing-with-effects#step-3-add-cleanup-if-needed)、開発中には React は<CodeStep step={1}>セットアップ</CodeStep>と<CodeStep step={2}>クリーンアップ</CodeStep>を、<CodeStep step={1}>セットアップ</CodeStep>の前に 1 回余分に実行します**。これは、副作用のロジックが正しく実装されていることを確認するストレステストです。これが目に見える問題を引き起こす場合、クリーンアップ関数に一部のロジックが欠けています。クリーンアップ関数は、セットアップ関数が行っていたことを停止ないし元に戻す必要があります。基本ルールとして、ユーザーはセットアップが一度しか呼ばれていない（本番環境の場合）か、*セットアップ* → *クリーンアップ* → *セットアップ*のシーケンス（開発環境の場合）で呼ばれているかを区別できないようにする必要があります。[一般的な解決法を参照してください](/learn/synchronizing-with-effects#how-to-handle-the-effect-firing-twice-in-development)。
+**[バグを見つけ出すために](/learn/synchronizing-with-effects#step-3-add-cleanup-if-needed)、開発中には React は<CodeStep step={1}>セットアップ</CodeStep>と<CodeStep step={2}>クリーンアップ</CodeStep>を、<CodeStep step={1}>セットアップ</CodeStep>の前に 1 回余分に実行します**。これは、副作用のロジックが正しく実装されていることを確認するストレステストです。これが目に見える問題を引き起こす場合、クリーンアップ関数に一部のロジックが欠けています。クリーンアップ関数は、セットアップ関数が行っていたことを停止ないし元に戻す必要があります。基本ルールとして、ユーザはセットアップが一度しか呼ばれていない（本番環境の場合）か、*セットアップ* → *クリーンアップ* → *セットアップ*のシーケンス（開発環境の場合）で呼ばれているかを区別できないようにする必要があります。[一般的な解決法を参照してください](/learn/synchronizing-with-effects#how-to-handle-the-effect-firing-twice-in-development)。
 
 **[各副作用を独立したプロセスとして記述](/learn/lifecycle-of-reactive-effects#each-effect-represents-a-separate-synchronization-process)するようにし、[一回のセットアップ／クリーンアップのサイクルだけを考える](/learn/lifecycle-of-reactive-effects#thinking-from-the-effects-perspective)ようにしてください**。コンポーネントが現在マウント、更新、アンマウントのどれを行っているかを考慮すべきではありません。セットアップロジックが正しくクリーンアップロジックと「対応」されることで、副作用はセットアップとクリーンアップを必要に応じて何度実行しても問題が起きない、堅牢なものとなります。
 
@@ -267,7 +267,7 @@ body {
 
 #### アニメーションのトリガ {/*triggering-an-animation*/}
 
-この例では、外部システムは `animation.js` に書かれているアニメーションライブラリです。これは、DOM ノードを引数に取る `FadeInAnimation` という JavaScript クラスを提供し、アニメーションを制御するための `start()` および `stop()` メソッドを公開しています。このコンポーネントは、背後にある DOM ノードにアクセスするために [ref を使います](/learn/manipulating-the-dom-with-refs)。副作用は ref から DOM ノードを読み取り、コンポーネントが表示されたときにそのノードのアニメーションを自動的に開始します。　
+この例では、外部システムは `animation.js` に書かれているアニメーションライブラリです。これは、DOM ノードを引数に取る `FadeInAnimation` という JavaScript クラスを提供し、アニメーションを制御するための `start()` および `stop()` メソッドを公開しています。このコンポーネントは、背後にある DOM ノードにアクセスするために [ref を使います](/learn/manipulating-the-dom-with-refs)。副作用は ref から DOM ノードを読み取り、コンポーネントが表示されたときにそのノードのアニメーションを自動的に開始します。
 
 <Sandpack>
 
@@ -1041,7 +1041,7 @@ export async function fetchBio(person) {
 
 - **副作用はサーバ上では動作しません**。これは、サーバレンダリングされた初期 HTML にはデータのないローディング中という表示のみが含まれてしまうことを意味します。クライアントのコンピュータは、すべての JavaScript をダウンロードし、アプリをレンダーした後になってやっと、今度はデータを読み込む必要もあるということに気付くことになります。これはあまり効率的ではありません。
 - **副作用で直接データフェッチを行うと、「ネットワークのウォーターフォール（滝）」を作成しやすくなります**。親コンポーネントをレンダーし、それが何かデータをフェッチし、それによって子コンポーネントをレンダーし、今度はそれが何かデータのフェッチを開始する、といった具合です。ネットワークがあまり速くない場合、これはすべてのデータを並行で取得するよりもかなり遅くなります。
-- **副作用内で直接データフェッチするということは恐らくデータをプリロードもキャッシュもしていないということです**。例えば、コンポーネントがアンマウントされた後に再びマウントされる場合、データを再度取得する必要があります。
+- **副作用内で直接データフェッチするということはおそらくデータをプリロードもキャッシュもしていないということです**。例えば、コンポーネントがアンマウントされた後に再びマウントされる場合、データを再度取得する必要があります。
 - **人にとって書きやすいコードになりません**。[競合状態](https://maxrozen.com/race-conditions-fetching-data-react-with-useeffect)のようなバグを起こさないように `fetch` コールを書こうとすると、かなりのボイラープレートコードが必要です。
 
 上記の欠点は、マウント時にデータをフェッチするのであれば、React に限らずどのライブラリを使う場合でも当てはまる内容です。ルーティングと同様、データフェッチの実装も上手にやろうとすると一筋縄ではいきません。私たちは以下のアプローチをお勧めします。
@@ -1250,7 +1250,7 @@ useEffect(() => {
 **空の依存配列であっても、セットアップとクリーンアップは[開発中には 1 回余分に実行](/learn/synchronizing-with-effects#how-to-handle-the-effect-firing-twice-in-development)され、バグを見つけるのに役立ちます**。
 
 
-以下の例では、 `serverUrl` と `roomId` の両方がハードコードされています。コンポーネントの外側で宣言されているため、これらはリアクティブな値ではなく、従って依存配列に入れる必要もありません。依存リストは空なので、再レンダー時にこの副作用が再実行されることもありません。
+以下の例では、`serverUrl` と `roomId` の両方がハードコードされています。コンポーネントの外側で宣言されているため、これらはリアクティブな値ではなく、従って依存配列に入れる必要もありません。依存リストは空なので、再レンダー時にこの副作用が再実行されることもありません。
 
 <Sandpack>
 
@@ -1722,7 +1722,7 @@ function Page({ url, shoppingCart }) {
 }
 ```
 
-**副作用イベントはリアクティブでなはいため、あなたの副作用の依存配列からは常に除く必要があります**。これにより、非リアクティブなコード（最新の props や state の値を読むことができるコード）を副作用イベント内に入れることができます。`onVisit`の中で `shoppingCart` を読むことで、`shoppingCart` が副作用を再実行することがなくなります。
+**副作用イベントはリアクティブでなはいため、あなたの副作用の依存配列からは常に除く必要があります**。これにより、非リアクティブなコード（最新の props や state の値を読むことができるコード）を副作用イベント内に入れることができます。`onVisit` の中で `shoppingCart` を読むことで、`shoppingCart` が副作用を再実行することがなくなります。
 
 [副作用イベントがリアクティブなコードと非リアクティブなコードをどのように分離するか詳しく読む](/learn/separating-events-from-effects#reading-latest-props-and-state-with-effect-events)。
 
@@ -1751,7 +1751,7 @@ function MyComponent() {
 }
 ```
 
-アプリがロードされている間、ユーザは初期レンダリングの出力を表示します。ロードとハイドレーションが完了したら、副作用が実行され、`didMount` が `true` にセットされ、再レンダーがトリガーされます。これにより、クライアント専用のレンダリング出力に切り替わります。副作用はサーバ上では実行されないため、初回サーバレンダリング時には `didMount` は `false` のままになります。
+アプリがロードされている間、ユーザは初期レンダーの出力を表示します。ロードとハイドレーションが完了したら、副作用が実行され、`didMount` が `true` にセットされ、再レンダーがトリガされます。これにより、クライアント専用のレンダー出力に切り替わります。副作用はサーバ上では実行されないため、初回サーバレンダー時には `didMount` は `false` のままになります。
 
 このパターンは節度を持って使用してください。遅い接続のユーザは初期コンテンツをかなり長い時間、場合によっては数秒以上表示することになります。なのでコンポーネントの見た目に違和感を与える変更をしないようにしてください。多くの場合、CSS で条件付きに異なるものを表示することで、このようなことはしなくてよくなります。
 
@@ -1763,7 +1763,7 @@ function MyComponent() {
 
 Strict Mode がオンの場合、開発時に React は実際のセットアップの前に、セットアップとクリーンアップをもう一度実行します。
 
-これは、副作用のロジックが正しく実装されていることを確認するためのストレステストです。これが目に見える問題を引き起こす場合、クリーンアップ関数に一部のロジックが欠けています。クリーンアップ関数は、セットアップ関数が行っていたことを停止ないし元に戻す必要があります。基本原則は、ユーザがセットアップが一度呼ばれた場合（本番環境の場合）と、セットアップ → クリーンアップ → セットアップ というシーケンスで呼ばれた場合（開発環境の場合）で、違いを見分けられてはいけない、ということです。
+これは、副作用のロジックが正しく実装されていることを確認するためのストレステストです。これが目に見える問題を引き起こす場合、クリーンアップ関数に一部のロジックが欠けています。クリーンアップ関数は、セットアップ関数が行っていたことを停止ないし元に戻す必要があります。基本原則は、ユーザがセットアップが一度呼ばれた場合（本番環境の場合）と、セットアップ → クリーンアップ → セットアップというシーケンスで呼ばれた場合（開発環境の場合）で、違いを見分けられてはいけない、ということです。
 
 [どのようにバグを見つけるのに役立つか](/learn/synchronizing-with-effects#step-3-add-cleanup-if-needed) と、[ロジックを修正する方法](/learn/synchronizing-with-effects#how-to-handle-the-effect-firing-twice-in-development) について詳しく読む。