はじめに こんにちは。株式会社HRBrainでインターンをしている安井です。 この記事では今業務で採用しているReact Queryの特性を生かした設計を考察してまとめていきます。 本記事はHRBrain Advent Calendar 2022の24日目の記事です。 前提 本記事で使用するライブラリ等のversion React: v18.2.0 TypeScript: v4.9.3 React Query（TanStack Query）: v4.19.1 axios: v1.2.1 vite: v4.0.0 React Queryはv4から名前が変更されTanStack Queryとなりましたが、記事の中ではReact Queryと呼ぶこととします。 また、本記事で使用するコードは下記のレポジトリで公開しています。 React Queryとは React Query is often

2022/11/26(土)で開催された JSConf JP 2022に関する、現時点での公開資料と Twitter アカウントリンクをまとめました。 よろしければご活用ください。 ※2022/11/28追記 ねぎしさんからいただいたコメントを元に、各講演に時間指定をした YouTube リンクを追記しました。 （時間指定をすると流石に動画埋め込みはできないようだったので、リンクでご容赦ください🙏） はじめに 登壇者名は敬称略させていただいています。 Twitter アカウントについては、ご本人が当イベントで登壇されることに言及されている、スライドに記載など、確認できたものを記載しております。 リンクの間違い等ありましたらコメントいただけると助かります🙏 アーカイブ動画 当イベントは、3つのトラックに分かれて講演が行われました。 その3つともアーカイブ動画が残っているので、後から見直すこ

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

Overview React Query はしばしば、React 用のデータフェッチングのためのライブラリだと言われるが、実際はフェッチングだけでなく、キャッシング及びサーバとの同期も行ってくれるライブラリだ。 開発動機 React 自体には、コンポーネントからデータフェッチしたり更新するための仕組みが提供されていないため、結局開発者それぞれが、独創的な方法を実施することになる(React Hooks 使うとか、もっと特化したライブラリに頼るとか) 成熟した状態管理ライブラリは、クライアントサイドの状態を管理する上では非常に優れているが、サーバサイドの状態を同期するのは困難である。 クライアントからみたサーバサイドの状態とは以下のようものだ リソースのロケーションが分離されてるので、クライアントサイド自身で管理することができない 非同期APIを叩いて更新するしかない データの所有権が分散し

TanStack Queryではデータを取得するuseQuery Hookだけではなくデータの作成/更新/削除を行うことができるuseMutation Hookもあります。useMutation Hookの動作確認をするためにバックエンドサーバを構築してデータベースを利用します。バックエンドサーバにはExpress, データベースにはSQLite、サーバとデータベースの仲介にPrismaを利用します。TanStack Queryだけではなくバックエンドサーバの環境方法についても一緒に学ぶことができます。 TanStack Queryとは TanStack Queryはバージョン3まではReact Queryと呼ばれていましたがバージョン4になり名称がTanStack Queryになりました。以前までのバージョンで利用されてきたReact Queryは名前にReactが含まれている通りRea

データフェッチで考えられるシナリオ パラメータ無しの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

React Query as a State Manager20.08.2021 — ReactJs, React Query, JavaScript, TypeScript — 7 min read React Query is loved by many for drastically simplifying data fetching in React applications. So it might come as a bit of a surprise if I tell you that React Query is in fact NOT a data fetching library. It doesn't fetch any data for you, and only a very small set of features are directly tied to

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点が自分が状態管理ライ

RTK Queryおもしろそうなので調べてみたり触ってみたりした。 どちらかというと雰囲気を伝えることを目的とした記事で、勘違いしている可能性もあるかもしれないので(つっこんでほしい) 詳細については公式を読んでください。 対象 Reactを使ってるひと Reactでのデータ取得のキャッシュの扱いとか管理がしんどいなってひと Reduxは分からなくてもOK RTK Query is 何？ Redux Toolkitのチームが作ったデータ取得とキャッシングのためのツール。 データを取得するのが楽になる。キャッシュのロジックを手書きする必要がなくなる。 最近のReactコミュニティでは「データの取得とキャッシュ」は「状態管理」を別のものとして管理したいという需要があった。 → RTK Queryは「データの取得とキャッシュ」に特化したツール。(Reduxは「状態管理」に特化したツール) 実際の

特に、React に React Hooks が導入されたり、async/await 記法が普及してきたりしたことなどを背景に、コンポーネントから直接 API を呼び出すことも簡単にできるようになってきました。 ちなみに、React Query などライブラリの話に入る前に注記しますが、この「Redux を剥がしてコンポーネントから直接 API データを取得する」ということは React だけの機能で（=他のライブラリ不要で）実現することもできます。具体的には以下のようなコードになります： さて、上記のような議論から、最近ではグローバルステートから「サーバーステート」（API から取得したデータに基づくステート）を切り出す流れも見られるようになりました。サーバーステートが切り出された後のグローバルステートは「クライアントステート」として扱うこともでき、以下のように整理することができます:

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) ); 基本的な使い方はこ