皆さんこんにちは。最近のReact界隈で話題になっているのは次のRFCです。 そこで、この記事ではさっそくRFCを理解することを目指します。 ただし、このRFCはSuspenseに深く関わるものです。SuspenseはReact 18でもう正式リリースされていますから、この記事ではSuspenseは前提知識とします。もしまだSuspenseをよく知らないのであれば、ぜひ次の記事で学習してください。 また、RFCはあくまでReactの新機能のアイデアを公開するものであり、これが必ず実装されるとは限らない点にご注意ください。例えば、過去にはuseEventというRFCが注目を集めていましたが、意見が集まった結果としてそのRFCは実装されずにクローズされました（RFCが無駄だったというわけではなく、再度検討してよりアイデアがブラッシュアップされることになります）。 新しい use API このR

データフェッチで考えられるシナリオ パラメータ無しのGET パラメータ有りのGET キャッシュ保持 キャッシュのinvalidate キャッシュしたデータに対するモデリング ReduxでいうcreateEntityAdapter的な プリフェッチ(+並行リクエスト) SSR対応 APIコールを行わずに初期値を渡せる 最大要件とインタフェースはReact Queryを参考にする すごいオプションあるけど実際に作ってて欲しくなるのは以下 onStart onEnd onSuccess onError refetchOnMount( or staleTime) また、ユーザー体験の観点で以下の要件を満たせると良い 楽観的UI Suspendせずにリフェッチ可能 (画面のチラつき防止) こうして考えたときにReact Queryはほぼ全ての要求を満たしていてさすがだと思う。 キャッシュも効くのでR

最近React Queryがv4になりました。 オプションのcacheTime, staleTimeについて何回ググっても忘れてしまうため、 例え話で理解してみようと思います。 公式ドキュメント cacheTime The time in milliseconds that unused/inactive cache data remains in memory. When a query's cache becomes unused or inactive, that cache data will be garbage collected after this duration. When different cache times are specified, the longest one will be used. 未使用/非活動状態のキャッシュデータがメモリ内に残る時間（ミリ秒

TL;DR TanStack Query や SWR のようなデータ取得ライブラリは、難しいとされる Server State 管理を簡単にします。ユーザビリティやコンポーネント設計の品質も向上させます。導入する際にはいくつか注意する点があります。 （かなり長くなってしまったため、目次や目に留まった箇所だけ読むのも良いかと思います） スコープ この記事は Client Side Rendering(CSR) の SPA を対象とします。筆者（の業務）の関心や要求が少ないため、SSR や ISR はこの記事の議論では対象にしません[1]。読み込みパフォーマンスについても要求は控えめです。 利点や議論は特定の UI ライブラリ・フレームワークに限りませんが、筆者が慣れている React を使って説明します。 予備知識 React の State について この記事では、React の Stat

Reduxを入れてない理由 作者のDan先生も言っていますが、必要にならなかったわけですね。 もっとReduxじゃないとキツい！ってなれば学んで入れようってモチベになるんですが案外なくてもいけちゃったなーというのが素直な感想。 Reduxが必要にならなかった理由 バックエンドがGraphQLで、GraphQLクライアントライブラリが優秀だったことが挙げられます。 Apollo Client URQL React Query 上記3つを使い現在はReact-Queryを使っているが、fetchデータの状態管理はReact Queryのcacheで十分賄えている。 Form周りはReact-hook-formをずっと使っているので（要はReact-hook-formのスポンサーです）Form周りでも特に必要としなかった。 非同期処理での状態管理 Formの状態管理 上記2点が自分が状態管理ライ

React Queryを使ってみて、設計に関して考えてみたので書いていきます。 ※注意点 今回はReact Queryの使い方や一番の持ち味であるキャッシュに関しては特に深ぼっていきません。 いかに分かりやすく、変化に強い設計ができるかをテーマに進めていきます。 React Queryの使い方 async function fetchUser(userId: number) { const response = await fetch( `http://localhost:5000/users/${userId}` ); return response.json(); } const { data, isError, error, isLoading, isFetching } = useQuery( 'user', () => fetchUser(userId) ); 基本的な使い方はこ

はじめに 筆者はOpenAPIスキーマからRTK Queryのコードを生成するrtk-query-codegen-openapiに2020年頃からコントリビュートを続けていました. rtk-query-codegen-openapiは現在rtk-incubatorリポジトリではなく、redux-toolkit/packages/rtk-query-codegen-openapiに統合されています. 今回は、RTK Queryを幾つかの現場で本番運用して得られた優位性を公開します. 他ツールとの機能比較 RTK QueryとReact Queryが作成したマトリックスがある為、リンクだけ貼って省略します RTK Queryが作成したマトリックス React Queryが作成したマトリックス Best Futures of RTK Query 他のdata fetchingライブラリと比べても

こんにちは、エンジニアの尾島(@daikiojm)です。 最近は HiCustomer のオフィスがある五反田周辺の飲食店の入れ替わりが激しく、開店/閉店に一喜一憂しております。 五反田、目黒周辺でおすすめのお店があったら教えてください。 React + Vite で新規プロダクトを開発している話で紹介した新プロダクトの開発では、GraphQL を採用しています。 今回はこの記事では紹介しきれなかった GraphQL Code Generator と React Query の活用について紹介します。 この記事で紹介する内容は次のとおりです。 GraphQL Code Generator + React Query の組み合わせを採用した理由 GraphQL Code Generator を使った型/React Query のクライントコード生成 Custom Hooks の実装例 Gra

MAD 事業部の高橋ゆうきです。 REST API である場合、プライベートでは SWR を使うことが多いのですが、昨年から案件では React Query を使っているのでいくつかの違いを感じることがありました。ここでは React Query のドキュメントにある表 から気になった違いをいくつかピックアップしてみます。 比較 Query Key Change Detection React Query - Deep Compare (Stable Serialization) SWR - Shallow Compare Deep Compare (Stable Serialization) 2021 年 2 月 20 日現在上記のように記載されていますが、SWR も 1.1.0 以降は ドキュメントにも記載されているように、stable serialization となっています。 Q

はじめに タイトルで大きくふろしきを広げてしまいましたが、結論から言うといろいろと試してみた結果、現時点ではまだ着地点を見出せていません。現時点での自分なりの最適解として、useQuery、usePrefetch、useMutationと楽観的更新の実装例についていくつか紹介させていただきます。 モチベーション 現在、Redux Sagaをふんだんに利用したアプリケーションのメンテナンス・機能拡張に携わっているのですが、ページ数やAPIエンドポイントが多数あることからコード量が多く構造も複雑になっており、メンテナンスコストの増大が懸念されるようになってきました。そこで今後のメンテナンス性の向上、また新規に参画するメンバーにも入りやすいようRedux SagaをはがしReact Queryへ少しずつ移行してくための検証を兼ねてReact Queryの使い方を探っています。 React Que