React Query を使っていて気になった SWR とのいくつかの違い | DevelopersIO
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
Storybook First な開発のススメ
Storybook first な開発とは Storybook での呼び出され方を意識しながらアプリケーションコードを書くことをそのように呼んでいます。 道具に設計がひきづられるのはアンチパターンと言われそうな気もするのですが、コンポーネントのカタログを整備していくことは、コンポーネントが良い感じに再利用可能な形で分離できるということでもあり、やっていくとむしろ正道に近づいていくと思います。 Storybook First のコンポーネント設計や型定義をすると、パーツに限らず Storybook でカバーできる範囲が広がり、ページそのもののサンドボックスを作れます。 そして API がない状態でもデータを使って開発ができたり、特定のスナップショットの再現やタイムトラベルに近いことも可能になるというメリットがあります。 つまり、ただのコンポーネントカタログとしてではなく、開発のためのサンドボ
SWR vs React Query - fsubal
#フロントエンド （※ この記事は API およびそこから導かれる設計のしやすさ観点での比較をしています。実際にキャッシュが有効に効いたか、などについてはまた別の機会に ） 動機 SPA の状態管理に必ずしも Redux いらないんじゃね問題 Redux が嬉しいのってクライアントサイドでモリモリ状態が変わる画面だけじゃん、みたいなアレ 検索結果の一覧みたいなページに Redux を使うの意味なかった 本当に必要なとこだけ使うようにしたい ほとんどのケースで欲しいのって React 向けの API クエリキャッシュ これまでは Redux の Store を単なるキャッシュとして使ってたが、違うよね 候補 ↑ みたいな話でよく上がるオルタナティブとして SWR と React Query がある これら 2 つを比較する。 TL;DR SWR の方が王道感を感じるけど、思ったより #rea
リモートのデータ取得のためのフックライブラリの SWR を使ってみる | メルカリエンジニアリング
こんにちは。Mercari Advent Calendar 2019 の 17 日目は Web UX Team 所属の @lightnet328 がお送りします。 どのようにリモートのデータを取得して管理するかは SPA 構成の Web フロントエンドにおいて大きなテーマの 1 つだと思います。最近では Apollo Client のようにデータ取得のためのクライアントとデータ管理のためのキャッシュ機構が一体化したライブラリが出てきています。 本稿で紹介する zeit/swr (以下、SWR) もそのような特徴を持っています。SWR はその名が示すとおり HTTP の stale-while-revalidate (略すと swr) というキャッシュ戦略に影響を受けているため、先に HTTP の state-while-ravalidate について紹介します。 HTTP の Cache-
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
