【脱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年の初旬でした。おそらく
kintoneマイクロサービス化検証プロジェクトのWebフロントエンドにおける技術選定 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロントエンドエキスパートチームのsakitoです。 本記事ではkintoneをマイクロサービス化するためのPoCプロジェクトにおけるWebフロントエンドの技術選定について紹介します。 プロジェクト背景 本記事で扱うプロジェクトは「kintoneマイクロサービス化Proof of concept(PoC)プロジェクト」です。 現在サイボウズの主力製品であるkintoneは大きなモノリシックなアーキテクチャになっています。 モノリシックなサービスに関わる人数が増えるに伴って、意思決定や開発速度の低下が課題となってきています。 モノリシックなアーキテクチャや組織によって起こる課題を、マイクロサービスとして切り離して小さくすることで解決ができるのではないかと考えました。マイクロサービス化にあたって、まずはPoCとして一部の機能をマイクロサービス化するプロジェクトを発足し、kinton
Jamstackを検討する - ゆーすけべー日記
Jamstackを既存のシステムに導入するかを検討する機会があった。 紆余曲折したものの、未だに暫定的な結論しか出ていない。 とはいえ、わりと頑張った。 今回は Jamstackとはなんぞや？ Jamstackの特徴 Jamstackの技術 弱みを解決する策 実際に検討した話 を雑に紹介したい。 個人的なメモなので、間違っているところがあるのを考慮願いたい。 Jamstackとは？ JamstackのJamは以下の頭文字をとっている。 JavaScript APIs Markup まず、フロントエンドを持たないAPI群がある。APIはブラウザのJavaScriptから叩かれるかもしれないし、後述するようなSSG =「Static Site Generator」のフレームワークが叩くかも知れない。どちらにせよユーザーに配信されるのはSSGが出力した、Markup。つまりプリレンダリングされた
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ヘッダー経由でサーバーと協調しながらキャッシュの有効期間を設定する手段が用意されていますね。サーバーやブラウザ側でキャッシュを制御してくれる
SWRで爆死を避ける。firebase Cloud FirestoreとNext.js。
はじめに 2か月前に「SWRを使おうぜという話」という記事を書きました。 Vercel謹製のSWRの便利さや導入の簡単さについて語りました。 そしてそれに感動を覚えたらとにかく使いたくなります。 だって既存のプロジェクトに導入するのも簡単だから（！） Firestore サーバーレスでのアプリケーションやデータをほとんど持たないwebサイトを作成するときは、私はfirebaseのFirestore(GCP)をよく利用します。 これもまたSWRなどと同じくとても簡単に導入できるので、各方面に推奨しております。 しかしFirestoreでの辛い点は、データの取得や更新に必要な手数の多さです。 通常の記載は下記。（※Typescriptを使用しております。） 投稿一つ型チェックするのにこのコーディング量！ type Categories = "ブログ" | "ニュース"; type Post =
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
より速い WEB を目指す Next.js / nextjs-make-the-web-faster