Linnoedge

React Query vs useEffect: データフェッチにおいてuseEffectだけでは不十分になるのはいつか？

React Query vs useEffect: データフェッチにおいてuseEffectだけでは不十分になるのはいつか？

Reactを学び始めた頃、API呼び出しは最も簡単な部分の1つだと思っていました。

いくつかのstateを作成します：

  • data
  • loading
  • error

そして、useEffectを使ってデータをフェッチします。

すべて順調に動作していました。

少なくとも、プロジェクトが大きくなり始めるまでは。

以前、KPIレポート画面を作成した時のことを覚えています。最初はデータを取得するAPIは1つだけでした。しかし、何度か改修を重ねるうちに、画面には以下の機能が追加され始めました：

  • 検索 (Search)
  • フィルター (Filter)
  • ページネーション (Pagination)
  • データの更新 (Data refreshing)
  • 更新後のデータ同期 (Data synchronization)

そして、その時コンポーネントが肥大化し始めました。

単にデータを表示するためだけに使われるべきものが、APIに関連するあらゆる処理を扱わなければならなくなったのです。

しばらくして、問題はReactやuseEffectにあるのではないことに気づきました。

問題は、サーバーからのデータをどのように管理しているかにありました。

React Query (TanStack Query) とは何か？

React Query（現在のTanStack Query）は、Reactアプリケーションにおけるサーバーステート（サーバー状態）の管理を支援するライブラリです。Webポータルの最適化であれ、React Nativeのようなフレームワークを用いた [モバイルアプリ開発] を検討しているのであれ、堅牢なステート管理はスムーズなユーザー体験の鍵となります。

以下の処理を行うために、独自のuseEffectやuseStateを書く代わりに：

  • Loading
  • Error
  • キャッシュ (Caching)
  • 再フェッチ (Refetching)
  • データ同期 (Data synchronization)

私たちは次のように宣言するだけで済みます：

  • データはどこから来るのか（queryFn）
  • そのデータは何か（queryKey）

残りの処理はReact Queryが行ってくれます。

シンプルに聞こえますが、これこそがReactのコードをはるかにクリーンにする理由です。

プロジェクトが成長するにつれて、なぜ useEffect + useState では不十分になるのか？

実際のところ、APIの呼び出しは数行のコードで済みます。

例えば：

JavaScript

const [users, setUsers] = useState([]);

useEffect(() => {
  fetchUsers();
}, []);

しかし、問題は最初のリクエストにあるのではありません。

問題は、その後にやってくるものにあります。

実際の画面を構築する際、通常は以下のものが必要になります：

  • Loadingステート
  • Errorステート
  • リクエスト失敗時のリトライ
  • データの更新
  • データのキャッシュ
  • 更新後のデータ同期

すべてのAPIが似たようなものを必要とします。

最初は気付きませんでした。

しかし、プロジェクトが成長し、何十もの画面が含まれるようになったとき、自分が多くの場所でまったく同じコードパターンを繰り返していることに気づきました。

唯一の違いはAPIの名前だけでした。

ReactコンポーネントがAPIロジックで過負荷になっている兆候

私は常に、コードを読んで何をしているのかがすぐに理解できるコンポーネントを好みます。

例えば：

  1. データを取得する
  2. UIをレンダリングする
  3. 完了。

しかし現実には、多くのコンポーネントが次第にあらゆるロジックの掃き溜めになってしまいます：

Plaintext

UserPage 
├── Fetch API 
├── Loading State 
├── Error State 
├── Retry Logic 
├── Refresh Logic 
├── Cache Logic 
└── UI Rendering

修正やデバッグが必要になった時、コードを読むのは非常に疲れます。

特に以下のようなシステムでは顕著です：

  • ダッシュボード (Dashboards)
  • CRM
  • レポートシステム (Reporting Systems)
  • 管理システム (Admin Systems)

多くのAPIが同時に動作している場所です。このような大規模プラットフォームの構築には、堅牢なアーキテクチャが必要です。複雑なデータフローへの対応をお考えの場合は、当社の[システム開発] アプローチについてもぜひご覧ください。

React Queryはこの問題をどのように解決するのか？

正直なところ、最初はReact Queryにあまり興味がありませんでした。

以前はこう思っていました： 「単にAPIを呼び出すだけなのに、別のライブラリが本当に必要なのか？」

しかし、実際のプロジェクトに適用してみると、違いが見え始めました。

最初に気に入ったのは、コンポーネントが短くなったことです。

データに関連する多くのstateを手動で管理する代わりに、データがどこから来るのかを宣言するだけで済むようになりました。

例えば：

JavaScript

const { data, isLoading, error } = useQuery({ 
    queryKey: ["users"], 
    queryFn: getUsers, 
});

そして、レンダリングに集中します：

JavaScript

if (isLoading) return <Loading />; 
if (error) return <Error />; 

return <UserTable users={data} />;

これを読めば、コンポーネントが何をしているのかが一瞬で理解できます。

React Queryの本当の利点はキャッシュではない

React Queryと聞くと、ほとんどの人がすぐにキャッシュを思い浮かべるでしょう。

確かに、キャッシュは非常に便利です。

ユーザーは画面間をより速く移動でき、サーバーが受け取るリクエストも減ります。

しかし、私にとってそれは最大の価値ではありません。

私が最も気に入っているのは、React QueryがUIをデータ管理ロジックから分離するのを助けてくれることです。

コンポーネントはレンダリングのみに集中できます。

Plaintext

React Component
       │
       ▼
TanStack Query
       │
 ┌─────┴─────┐
 ▼           ▼
Cache       API
 │
 ▼
UI Update

以下のようなものは：

  • Loading
  • Retry
  • Refetch
  • Cache

…本来あるべき場所に置かれます。

おかげで、コードははるかに読みやすくなりました。

React Query vs Redux：サーバーステートにはどちらを使うべきか？

以前私がやっていたことの1つは、多くのAPIデータをReduxに入れることでした。

例えば：

  • ユーザー (Users)
  • 注文 (Orders)
  • 製品 (Products)
  • レポート (Reports)

しばらくすると、ストアは巨大になりました。

深く掘り下げてみると、サーバーから取得したデータは、全く異なるタイプのstateであることに気づきました。

以下のものが必要になります：

  • キャッシュ (Caching)
  • 同期 (Synchronization)
  • 再フェッチ (Refetching)
  • 定期的な更新 (Periodic updates)

それこそが、React Queryが解決するために生まれた問題なのです。

これは、React QueryがReduxを置き換えるという意味ではありません。

  • Redux は クライアントステート (client state) に適しています。
  • React Query は サーバーステート (server state) に適しています。

React Queryを採用して以来、Reduxに保存するAPIデータの量は大幅に減少しました。

いつReact Queryを使うべきか？いつuseEffectで十分なのか？

もし以下のものを構築しているなら：

  • ランディングページ
  • 紹介ウェブサイト
  • いくつかのシンプルなAPI

…useEffect で全く問題ありません。

しかし、プロジェクトに以下のものが含まれ始めたら：

  • ダッシュボード
  • CRM
  • ERP
  • レポートシステム
  • 管理ポータル

…React Queryの利点は非常に明確になります。

特に、APIの数が増えるにつれて。

結論

Reactを数年間使ってきて、一番難しいのはAPIを呼び出すことではないと気づきました。

一番難しいのは、アプリケーションの規模が拡大するにつれて、データを一貫して管理することです。

TanStack Queryは、過剰に魔法のようなことをするわけではありません。

ほぼすべてのReactプロジェクトが最終的に直面するであろう問題を、見事に解決してくれるだけです。

私にとって、React Queryの最大の価値はキャッシュやパフォーマンスではありません。

それは、コンポーネントをその本来の役割、つまりUIのレンダリングに戻すのを助けてくれることです。

Reactファイルを開いて、コードの大部分がデータフェッチのロジックではなくUIであるのを見たとき、自分のコードベースがよりクリーンになっていると実感します。

フロントエンドとバックエンドの両方で最新技術を用いてWebアプリケーションを構築しています。拡張性、パフォーマンス、そして継続的な改善に情熱を注いでいます。