はじめに 最近、ReactやVueの公式ドキュメントを読んで、その原理原則を深く追求することにちょっぴりハマっています。今日は、そんな中から、Reactの根幹である純粋性と副作用について考えました。公式ドキュメントの説明や例って、びみょ〜に分かりづらいんですよね…今回はそれを、少しだけ自分ごとになるように言語化してみました。 1. 純粋関数とは まずReact抜きで、ただのJavaScriptの話です。 純粋関数の条件は2つだけです。 同じ入力なら必ず同じ出力 呼んでも外の世界を変えない // 純粋 function double(n) { return n * 2; } double(3); // 6 double(3); // 6 ← 何回呼んでも同じ！ 数学の世界では、これは当たり前のことです。そもそも純粋でない関数というのは定義上存在しません。でも、プログラミングでは、コードの書き

はじめに 「useEffectでデータ取得するのはやめた方がいい」— こんな話を聞いたことはないだろうか。 でも自分はずっと、useEffect + fetch でAPIを叩いていた。中でtry-catchして、useStateにセットして、ローディングもエラーも自分で管理して。チュートリアルで覚えたそのパターンを、特に疑うこともなく使い続けていた。 「やめた方がいいのは分かった。じゃあ何を使えばいいの？」— この記事は、その疑問に対する自分なりの答えを、実際にTanStack Queryに置き換えてみた過程から書いている。 useEffect + fetch で書くとこうなる 例として、APIから投稿一覧を取得して表示するコンポーネントを考える。 const [posts, setPosts] = useState<Post[]>([]); const [isLoading, setIs

はじめに 2025年10月にReact19.2がリリースされました。 React19.2で実装された新機能の中から、今回は特にActivityとuseEffectEventについて紹介したいと思います。 Activityコンポーネント Activityはvisibleとhiddenのモードを切り替えることでUIの表示/非表示を切り替えることのできるコンポーネントです。 従来は条件付きレンダリングやCSSを使用して表示を切り替える方法がありましたが、それぞれ欠点があります。 条件付きレンダリングでコンポーネントをアンマウントする場合： コンポーネント内に保持していたStateはアンマウントしたタイミングで消えてしまいます。 CSSで表示を隠す場合： 状態は保持されますが、コンポーネントは生きているためバックグラウンドで不要なレンダリングやEffectが走り続けてしまいます。 Activity

フロントエンドカンファレンス関西2025の登壇資料です。 https://fortee.jp/fec-kansai-2025

Reactにおいてプロダクトの品質を高く保つには、Reactのやり方に合ったコードを書くことが重要です。公式ドキュメントの名物ページ「そのエフェクトは不要かも」には、useEffectの望ましくない使い方と、それに代わるテクニックが紹介されています。 この記事で取り上げるのは、その中でも「props が変更されたときに一部の state を調整する」のセクションで紹介されている、レンダリング中にステートを更新するテクニックです。 このテクニックは一見すると奇妙で、知ってはいるけど使っていいのかよく分からないという方も多そうです。しかし、一見突飛に見える記述でも、深く理解すれば実はReactのデザインに完璧に則っているというのがReactの公式ドキュメントの特徴です。技術に対する向き合い方として、公式の説明であっても妄信せず批判的に見ることはとても重要です。しかし、Reactの場合は最終的に

depsに入れなくて良い、ではなく、入れてはならない です。 エフェクトイベント関数をdepsに入れるとレンダリング毎にエフェクトが走る useEffectEventは レンダリングごとに新しい関数を返します (検証用デモ)。 そのため、useEffect の deps にエフェクトイベントを含めると毎回エフェクトが実行されます(時にはこれによって 無限ループが起きます ) const effectEventFn = useEffectEvent(callback); // レンダリングのたびに新しい関数が返される useEffect(() => { return listen(effectEventFn); }, [effectEventFn]); // ❌ effectEventFn が入っているので毎回実行される!! なので、depsにeffectEventFnを入れてはいけません。

Meta社が「useEffectの46%は不要だった」という調査結果を発表。それを知った私が、自分のコードを見直してuseEffectを減らしていった体験談。連鎖するuseEffectでデバッグに苦労した経験から、どうやって改善していったかを共有。 useEffectを使いすぎてた私がMeta社の調査結果を見て反省した話 こんにちは。とちです。 Reactで開発していて、「useEffect書きすぎかも…」と感じたことはありませんか？私はしょっちゅうありました。 そんな中、Meta社（旧Facebook）が自社のコードベースを調査したら、useEffectの約46%が実は不要だったという調査結果を知って、かなり衝撃を受けました。 この記事では、私がuseEffectを使いすぎていた理由を反省しつつ、どうやって減らしていったかを共有します。 React公式ガイドライン：useEffectは「

Reactにおいては、コンポーネントは純粋であるべきだとされています。これはReactのルールの一部であり、ルールを守らずに非純粋なコンポーネントを作った場合、さまざまな不都合が発生する恐れがあります。 書いた通りの挙動にならない（ように見える） 今はうまく動いていたとしても、関係ない箇所を修正すると急に壊れる 最適化（React Compiler）によって挙動が変わり、バグの原因となる Reactの新機能と互換性が無くなり、新機能の恩恵を受けられなくなる Reactのアップデートで壊れてしまったり、破壊的変更の影響を受けたりする 単純にコードの可読性が低下し、保守性が悪化する では、コンポーネントが “純粋” であるとは、具体的にどういうことを指すのでしょうか。Reactを使いこなしている人は経験的にこのことを理解していますが、正確に説明しろと言われると困る人も多いのではないでしょうか。

「なにをしたいuseEffectか」をコメントしておくと、後で読むときのコストが下がりやすい。 実際にプロダクトコードで書いたことがあるコメント↓ (簡略化してます) // 画面内に入った動画を自動再生する+ほかの動画は停止する (すでに再生済みだったら再生しない) useEffect(() => { if (inView && !hasBeenPlayed && canAutoplay) { /* ... */ pauseOtherVideo(); play(); } /* ... */ }); このコンポーネントにはコレを含めて4つのコメント付きのuseEffectがあった。たびたび読み返す機会があったが、その度にこれらのコメントが大いに役立った。 なぜコメントが必要なのか? useEffectの中身はたいてい複雑な処理になる。しかもたいてい無名関数を渡すので、実現したい仕様に関する情

ReactのuseEffectは、フックの中でも使い方が難しいものの一つです。そこで、この記事では筆者が考えるuseEffectの望ましい使い方を皆さんに伝授します。 基本原則 技術やその要素の使い方を考えるにあたって、筆者が好んでいるのは基本原則を置いてそれに基づいて判断することです。ということで、この記事ではまず筆者が考えるReactの基本原則を紹介します。 筆者がもっとも重要視する原則は、ReactはUIライブラリであるということです。つまり、ReactにはUIの管理をさせるべきであって、その他のことはReactの役目ではないということです。Reactが難しいと思う人がいる場合、何でもかんでもReactにやらせようとするから余計に難しくなっているのだと思います。 例えばアプリケーションのロジックの管理やそれに付随するステートの管理はReactの役目ではないので、Reactの外部で処理