【脱Redux】SWRやReact Queryを使った状態管理戦略
mutexの桝田です！ Reactのデータフェッチに、Vercel社が提供する「SWR」やTanStackコミュニティが提供する「React Query（TanStack Query）」が使われることが多くなってきています。 これらのライブラリは単なるフェッチだけでなく、キャッシュやデータの更新を担ってくれます。また、Reactが志向する「宣言的」な記述を体現できることも大きなメリットです。 本稿では、（我々が採用する）React Queryにフォーカスし、React Queryを使って実現している状態管理について説明します。SWRを普段お使いの方に関してもかなり共通する部分が多いのではないかと思います。 1. 対象読者 Reactのデータフェッチライブラリの使用を検討している方 普段SWRやReact Queryを使用している方 普段Reactを使用するすべての方
ReactのSuspenseを使った非同期処理のエラーハンドリング
「フロントエンドLT会 - vol.8」で発表したスライドです。 https://rakus.connpass.com/event/255095/
React Queryを使いこなすために試したこと
はじめに タイトルで大きくふろしきを広げてしまいましたが、結論から言うといろいろと試してみた結果、現時点ではまだ着地点を見出せていません。現時点での自分なりの最適解として、useQuery、usePrefetch、useMutationと楽観的更新の実装例についていくつか紹介させていただきます。 モチベーション 現在、Redux Sagaをふんだんに利用したアプリケーションのメンテナンス・機能拡張に携わっているのですが、ページ数やAPIエンドポイントが多数あることからコード量が多く構造も複雑になっており、メンテナンスコストの増大が懸念されるようになってきました。そこで今後のメンテナンス性の向上、また新規に参画するメンバーにも入りやすいようRedux SagaをはがしReact Queryへ少しずつ移行してくための検証を兼ねてReact Queryの使い方を探っています。 React Que
React SPA の技術選定で考えたこと（atama plus のケーススタディ）
atama plus の osuzu です。 atama plus では、これから段階的に Web ベースプロダクトのフロントエンド開発で React を用いて SPA(Single Page Application) へリプレイスしていきます。 参考: 技術課題のないプロダクトなんてものはない！Django→React リプレイスの意思決定に至る atama plus 流の軌跡 この記事では SPA の技術選定にあたって考えたことを共有します。 プロダクトについて 技術選定はプロダクトの置かれた状況によって意思決定が変わると考えているので、リプレイスするプロダクトについて補足します。 atama plus は塾などで利用可能な学習アプリ「atama＋」を提供していますが、一連のプロダクトの中に塾本部の方が管理のために用いる業務アプリがあります。 今回リプレイスするのはこちらの業務アプリで
Design Doc for react-boilerplate-2022
これは何? React(Next.js)アプリケーションのテンプレートのための Design Doc React(Next.js)アプリケーションのテンプレートとして実装したリポジトリ shimpeiws/react-boilerplate-2022 の設計についてのDesign Docです SSR/ISRはせずnext exportしてStatic Fileを出力する構成です API Routesを使っていますが、API接続コードをローカルで動作させるためのもので本番動作させるためのものではありません Design Doc 本ドキュメントは実装したリポジトリの構成、ライブラリの選定理由など設計についての背景を示すためのドキュメントという位置づけです 「デザインドックで学ぶデザインドック」(https://www.flywheel.jp/topics/design-doc-of-desig
React周りのいつかお世話になる記事たち（随時更新）
Reactで開発をしていく上でみなさんがいつかお世話になるだろうと思った記事たちです。 （僕はお世話になりました。これからもお世話になります。） これも良かったよっていう記事があればコメントで教えてください！ 🌟 = 特におすすめ Reactを最初から学ぶ・入門 React Docs BETA 🌟 りあクト！ TypeScriptで始めるつらくないReact開発 第4版【① 言語・環境編】 - くるみ割り書房 ft. React - BOOTH 🌟 Reactハンズオンラーニング 第2版 ―Webアプリケーション開発のベストプラクティス RailsエンジニアのためのNext.js入門 - hokaccha memo React Glossary + Explain Like I'm Five 🌟 React Server Components 総まとめ Reactのレンダリングに関
「3種類」で管理するReactのState戦略
こんにちは、よしこです。 この記事は 2020年に立ち上げたWebフロントエンド構成の振り返り の「Stateのアーキテクチャ」項の詳細記事です。単体でも読めますが、よければ元記事もあわせてどうぞ！ この記事では、今わたしが開発・運用しているアプリケーションのState戦略についてご紹介していきます。 全体像 アプリケーションに存在する状態（State）を以下の3種類に分類し、それぞれのやり方で管理しています。 サーバーデータのキャッシュ Global State Local State 1. サーバーデータのキャッシュ 「SPAで管理する必要のあるGlobal Stateって、そのうちほとんどがサーバーデータのキャッシュだよね。それを取り除けたら、管理する必要のあるGlobal Stateってすごく小さくなるんじゃない？」という主張を私が認識しはじめたのが2020年の初旬でした。おそらく
React Hooks向けライブラリSWRとは？ 通信とキャッシュ管理を簡便に
対象読者 JavaScriptとWeb開発の基礎に理解がある方 Reactを用いたJavaScriptアプリケーション開発の経験者 前提環境 筆者の検証環境は以下の通りです。 macOS Big Sur 11.2.1 Node.js 15.8.0／npm 7.5.0 React 17.0.1 react-scripts 4.0.2 SWR 0.4.2 React Hooksで通信結果をキャッシュする アプリケーション開発において、外部システムとのIO処理はパフォーマンスのボトルネックになりがちです。特に、ネットワークを介した通信はその最たるものでしょう。これを解決するための手法の一つとして、キャッシュ機構を利用する方法があります。ブラウザにも、HTTPヘッダー経由でサーバーと協調しながらキャッシュの有効期間を設定する手段が用意されていますね。サーバーやブラウザ側でキャッシュを制御してくれる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
より速い WEB を目指す Next.js / nextjs-make-the-web-faster