エフェクトの依存配列まわりの記述を読みやすく

Author: honey32

src/content/blog/2025/04/23/react-labs-view-transitions-activity-and-more.md

@@ -14282,13 +14282,13 @@ useEffect(() => {
 }, [roomId]);
 ```
 
-多くのユーザはこのコードを「マウント時に `roomId` に接続し、`roomId` が変更されるたびに古いルームから切断して接続を再確立する」のように読んでしまいます。しかしこれでは、コンポーネントのライフサイクルの視点から考えてしまっています。つまり、エフェクトを正しく書くためにコンポーネントライフサイクルの全状態を考える必要があるのです。これは難しいことです。コンポーネントの視点で考えていると、エフェクトがクラスのライフサイクルよりも難しいと感じてしまうのは理解できます。
+多くのユーザはこのコードを「マウント時に `roomId` に接続し、`roomId` が変更されるたびに古いルームから切断して接続を再確立する」のように解釈してしまいます。しかし、このようにコンポーネントのライフサイクルの視点で考えると、エフェクトを正しく書くにはコンポーネントライフサイクルの全状態を考慮する必要があることになってしまいます。これは難しいことなので、コンポーネント視点だとクラスのライフサイクルよりもエフェクトの方が難しく見えるのは、無理もないことです。
 
 ### 依存配列のないエフェクト {/*effects-without-dependencies*/}
 
 代わりに、エフェクトの視点から考える方がベターです。エフェクトはコンポーネントのライフサイクルについて知りません。同期を開始する方法と停止する方法が記述されているだけです。ユーザがこのようにエフェクトを考えることでエフェクトは書きやすくなり、必要次第で何度も開始・停止されることに対して、より頑強になります。
 
-エフェクトをコンポーネントの視点から考えてしまう理由について時間をかけて調査し、その一因が依存配列にあると考えるようになりました。常に目の前にあって書かなければならないもののため、コードが何に「反応」しているのかを意識せざるを得ず、だから「これらの値が変わったらこれを行え」式のメンタルモデルに誘い込まれてしまうのです。
+私たちは、エフェクトをコンポーネントの視点から考えてしまう理由について時間をかけて調査し、その一因が依存配列にあると考えるようになりました。常に目の前にあって書かなければならないもののため、コードが何に「反応」しているのかを意識せざるを得ず、だから「これらの値が変わったらこれを行え」式のメンタルモデルに誘い込まれてしまうのです。
 
 フックをリリースした当時から、事前コンパイルでこの使いやすさを改善できることは分かっていました。React Compiler を使用すると、ほとんどの場合、自分で `useCallback` や `useMemo` を書く必要がなくなります。エフェクトの場合、コンパイラが依存配列を自動的に挿入できるようになります。
 
@@ -14302,7 +14302,7 @@ useEffect(() => {
 }); // compiler inserted dependencies.
 ```
 
-このコードでは、依存配列を React Compiler が自動的に推論して挿入するため、見たり書いたりする必要がありません。[IDE 拡張](#compiler-ide-extension)や [`useEffectEvent`](/reference/react/useEffectEvent) のような機能を使用することで、デバッグが必要なときや依存値を削除して最適化したい時のために、コンパイラが挿入したものを表示する CodeLens を提供できます。これにより、エフェクトを書くための正しいメンタルモデルが強化され、コンポーネントやフックの state を他のものと同期させるために任意のタイミングで実行できるエフェクトが書けるようになるでしょう。
+このコードでは、依存配列を React Compiler が自動的に推論して挿入するため、見たり書いたりする必要がありません。[IDE 拡張](#compiler-ide-extension)や [`useEffectEvent`](/reference/react/useEffectEvent) のような機能を使用することで、デバッグが必要なときや依存値を削除して最適化したい時のために、コンパイラが挿入したものを表示する CodeLens を提供できます。これにより、エフェクトを書くための正しいメンタルモデル、つまり、エフェクトはコンポーネントやフックの state を他のものと同期させるためにいつでも実行されうる、というメンタルモデルが補強されます。
 
 依存配列の自動挿入について我々が期待しているのは、ただ書きやすくなるというだけのことではありません。コンポーネントのライフサイクルではなく「エフェクトが何をするのか」という視点で考えることを強制し、理解がしやすくなることを期待しています。