メインコンテンツにスキップ

他のツールとの比較

RTK Queryは、エコシステム内の他の多くのデータフェッチライブラリからインスピレーションを得ています。ReduxコアライブラリがFluxやElmのようなツールに触発されたように、RTK Queryは、React Query、SWR、Apollo、Urqlのようなライブラリによって普及したAPI設計パターンと機能コンセプトを基に構築されています。RTK Queryはゼロから書き直されていますが、これらのライブラリや他のデータフェッチツールの最良のコンセプトを利用し、Reduxのユニークな強みと機能を活用することを目指しています。

これらのツールはすべて素晴らしいと考えています！もしあなたがそれらのいずれかを使用しており、満足していて、アプリで直面している問題を解決しているのであれば、そのツールを使い続けてください。このページの情報は、機能、実装アプローチ、およびAPI設計に違いがある場所を示すことを目的としています。目標は、ツールXがツールYよりも優れていると主張するのではなく、情報に基づいた意思決定を行い、トレードオフを理解するのを支援することです。

RTK Queryをいつ使用すべきか？​

一般的に、RTK Queryを使用する主な理由は以下のとおりです。

  • すでにReduxアプリがあり、既存のデータフェッチロジックを簡素化したい場合
  • Redux DevToolsを使用して、時間の経過に伴う状態の変化の履歴を確認できるようにしたい場合
  • RTK Queryの動作をReduxエコシステムの他の部分と統合できるようにしたい場合
  • アプリのロジックがReactの外で動作する必要がある場合

独自の機能​

RTK Queryには、考慮に値する独自のAPI設計の側面と機能がいくつかあります。

  • React QueryとSWRでは、通常、自分でフックを定義し、それをどこでもその場で行うことができます。RTK Queryでは、事前に複数のエンドポイントを持つ「APIスライス」を定義することで、1箇所でそれを行います。これにより、トリガー時に自動的にクエリを無効化/再フェッチする、より緊密に統合されたモデルが可能になります。
  • RTK Queryはリクエストが処理される際に通常のReduxアクションをディスパッチするため、すべてのアクションがRedux DevToolsで表示されます。さらに、すべてのリクエストは自動的にReduxリデューサーに表示され、必要に応じてグローバルアプリケーション状態を簡単に更新できます（例を参照）。エンドポイントマッチャー機能を使用して、独自のリデューサーでキャッシュ関連のアクションを追加処理できます。
  • Redux自体と同様に、RTK Queryの主な機能はUIに依存せず、任意のUIレイヤーで使用できます
  • ミドルウェアからエンティティを簡単に無効化したり、既存のクエリデータを（util.updateQueryDataを介して）パッチ適用したりできます。
  • RTK Queryは、websocketを介してメッセージを受信したときに、最初にフェッチされたデータを更新するなど、ストリーミングキャッシュの更新を可能にし、オプティミスティックアップデートも組み込みでサポートしています。
  • RTK Queryは、非常に小さく柔軟なフェッチラッパーであるfetchBaseQueryを提供しています。また、axios、redaxios、またはカスタムのものなど、クライアントを独自のものと交換するのも非常に簡単です。
  • RTK Queryには、OpenAPI仕様またはGraphQLスキーマを受け取り、型付きAPIクライアントを提供し、後で生成されたクライアントを拡張するためのメソッドを提供する（現在実験的な）コード生成ツールがあります。

トレードオフ​

正規化または重複排除されたキャッシュなし​

RTK Queryは、複数のリクエストにわたって同一のアイテムを重複排除するキャッシュを意図的に実装していません。これにはいくつかの理由があります。

  • 完全に正規化された、クエリ間で共有されるキャッシュは、解決が難しい問題です
  • 現時点では、それを解決しようとする時間、リソース、関心がありません
  • 多くの場合、無効化されたときにデータを再フェッチするだけでうまく機能し、理解しやすいです
  • 少なくとも、RTKQは「データをフェッチする」という一般的なユースケースを解決するのに役立ちます。これは多くの人にとって大きな悩みの種です

バンドルサイズ​

RTK Queryは、アプリのバンドルサイズに固定の1回限りの量を追加します。RTK QueryはRedux ToolkitとReact-Reduxの上に構築されているため、追加されるサイズはアプリで既にそれらを使用しているかどうかによって異なります。推定されるmin+gzipバンドルサイズは次のとおりです。

  • すでにRTKを使用している場合：RTK Queryの場合は〜9kb、フックの場合は〜2kbです。
  • まだRTKを使用していない場合
    • Reactなしの場合：RTK+依存関係+RTK Queryの場合は17 kB
    • Reactありの場合：19kB + React-Redux（ピア依存関係）

追加のエンドポイント定義は、endpoints定義内の実際のコードに基づいてのみサイズを増やす必要があります。通常、これは数バイト程度です。

RTK Queryに含まれる機能は、追加されたバンドルサイズにすぐに見合う価値があり、手書きのデータフェッチロジックを排除することで、ほとんどの有意義なアプリケーションでサイズが全体的に改善されるはずです。

機能セットの比較​

すべてのこれらのツールの機能セットを比較して、類似点と相違点を把握する価値があります。

情報

この比較表は、可能な限り正確で偏りのないものにするよう努めています。これらのライブラリのいずれかを使用しており、情報が改善される可能性があると感じた場合は、問題を提起することで、（主張のメモまたは証拠を添えて）変更を提案してください。

機能rtk-queryreact-queryapollourql
サポートされているプロトコル任意、RESTを含む任意、含まれるものなしGraphQLGraphQL
API定義宣言型使用時、宣言型GraphQLスキーマGraphQLスキーマ
キャッシュの基準エンドポイント+シリアル化された引数ユーザー定義のクエリキータイプ/IDタイプ/ID？
無効化戦略 + 再フェッチ宣言型、タイプおよび/またはタイプ/ID別キャッシュキーによる手動エンティティレベルでの自動キャッシュ更新、キャッシュキーによる手動クエリ無効化宣言型、タイプ別またはエンティティレベルでの自動キャッシュ更新、キャッシュキーによる手動クエリ無効化
ポーリングはいはいはいはい
並列クエリはいはいはいはい
依存クエリはいはいはいはい
スキップクエリはいはいはいはい
ラグのあるクエリはいはいいいえ?
自動ガベージコレクションはいはいいいえ?
正規化されたキャッシュいいえいいえはいはい
無限スクロールTODOはい手動コードが必要?
プリフェッチはいはいはいはい？
リトライはいはい手動コードが必要?
オプティミスティックアップデート手動でキャッシュを更新可能手動でキャッシュを更新可能optimisticResponse?
手動キャッシュ操作はいはいはいはい
プラットフォームReactのフック、Reduxが動作するすべての場所Reactのフック様々様々

詳細情報​

最終更新