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のレンダリングに関
より速い WEB を目指す Next.js / nextjs-make-the-web-faster
【Next.js Update!】v12リリースを踏まえ、Next.jsの採用を考える 本発表は以下URLでアーカイブ視聴が可能です。https://youtu.be/KaS3bgz_CA4 イベントページ：https://forkwell.connpass.com/event/228457/
こんにちは、よしこです。 この記事は 2020年に立ち上げたWebフロントエンド構成の振り返り の「Stateのアーキテクチャ」項の詳細記事です。単体でも読めますが、よければ元記事もあわせてどうぞ！ この記事では、今わたしが開発・運用しているアプリケーションのState戦略についてご紹介していきます。 全体像 アプリケーションに存在する状態（State）を以下の3種類に分類し、それぞれのやり方で管理しています。 サーバーデータのキャッシュ Global State Local State 1. サーバーデータのキャッシュ 「SPAで管理する必要のあるGlobal Stateって、そのうちほとんどがサーバーデータのキャッシュだよね。それを取り除けたら、管理する必要のあるGlobal Stateってすごく小さくなるんじゃない？」という主張を私が認識しはじめたのが2020年の初旬でした。おそらく
Jamstackを検討する - ゆーすけべー日記
Jamstackを既存のシステムに導入するかを検討する機会があった。 紆余曲折したものの、未だに暫定的な結論しか出ていない。 とはいえ、わりと頑張った。 今回は Jamstackとはなんぞや？ Jamstackの特徴 Jamstackの技術 弱みを解決する策 実際に検討した話 を雑に紹介したい。 個人的なメモなので、間違っているところがあるのを考慮願いたい。 Jamstackとは？ JamstackのJamは以下の頭文字をとっている。 JavaScript APIs Markup まず、フロントエンドを持たないAPI群がある。APIはブラウザのJavaScriptから叩かれるかもしれないし、後述するようなSSG =「Static Site Generator」のフレームワークが叩くかも知れない。どちらにせよユーザーに配信されるのはSSGが出力した、Markup。つまりプリレンダリングされた
そうです。わたしがReactをシンプルにするSWRです。
この記事について SWR について色々と学んだので、その知見をここで共有したいと思います 💪 ※ 基本的に以下の公式サイトの情報を参考にしています 📖 そのため、この記事で出すサンプルコードなどは主に上記の公式サイトから引用させてもらっています。予めご了承ください 🙏 SWR とは何か？ SWR は、Next.js を作っているVercel 社が開発しているデータフェッチのための React Hooks ライブラリです。"SWR"と言う名前は、 stale-while-revalidate の頭文字をとって名付けられています。そのため、SWR はstale-while-revalidateに基づいた処理と設計になっています。 stale-while-revalidateについて解説したい所ですが、解説するとすごく長くなってしまうため、ここでは「 キャッシュをなるべく最新に保つ機能 」
kintoneマイクロサービス化検証プロジェクトのWebフロントエンドにおける技術選定 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロントエンドエキスパートチームのsakitoです。 本記事ではkintoneをマイクロサービス化するためのPoCプロジェクトにおけるWebフロントエンドの技術選定について紹介します。 プロジェクト背景 本記事で扱うプロジェクトは「kintoneマイクロサービス化Proof of concept(PoC)プロジェクト」です。 現在サイボウズの主力製品であるkintoneは大きなモノリシックなアーキテクチャになっています。 モノリシックなサービスに関わる人数が増えるに伴って、意思決定や開発速度の低下が課題となってきています。 モノリシックなアーキテクチャや組織によって起こる課題を、マイクロサービスとして切り離して小さくすることで解決ができるのではないかと考えました。マイクロサービス化にあたって、まずはPoCとして一部の機能をマイクロサービス化するプロジェクトを発足し、kinton
mutexの桝田です！ Reactのデータフェッチに、Vercel社が提供する「SWR」やTanStackコミュニティが提供する「React Query（TanStack Query）」が使われることが多くなってきています。 これらのライブラリは単なるフェッチだけでなく、キャッシュやデータの更新を担ってくれます。また、Reactが志向する「宣言的」な記述を体現できることも大きなメリットです。 本稿では、（我々が採用する）React Queryにフォーカスし、React Queryを使って実現している状態管理について説明します。SWRを普段お使いの方に関してもかなり共通する部分が多いのではないかと思います。 1. 対象読者 Reactのデータフェッチライブラリの使用を検討している方 普段SWRやReact Queryを使用している方 普段Reactを使用するすべての方
これは何? 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
Next.js + Vercel + swr + TypeScript (No Redux + No SSR) で短期間チーム開発した - またのきかいに
はじめに タイトルにある通り Next.js + Vercel + swr + TypeScript という構成で短期間チーム開発をした。 以下のように特殊な状況なので色々試してみた。 開発状況 約3週間の短期間開発。 世間にリリースしない。プロトタイプを作って終了。メンテナンスもしない。 フロントエンドを触るのは自分を含めて3人。 自分・フロントの経験もあるバックエンドエンジニア・フロントエンドの経験が浅いエンジニアの3人。 ログイン機能有りのSNS的なもの。既に世の中に存在するプロダクトと似てる。 それぞれ選定理由と使用感を雑に書いていく。 Next.js github.com 環境構築が楽 Node.js環境さえ整えてもらえればすぐ動く。 ライブラリが最小限で済む Create React Appも環境構築が楽だが使われているライブラリのドキュメントを探すのが初学者には少しハードルが
【React】useSWRはAPIからデータ取得をする快適なReact Hooksだと伝えたい - パンダのプログラミングブログ
Vercel製のuseSWRはReactの非同期データ取得をラクにする SWRとは、Next.jsを作成しているVercel製のライブラリです。**SWRはuseSWRというReact Hooksを提供し、APIを通じたデータの取得をラクに記述する手助けをしてくれます。**このライブラリはなんとGitHubスター数を10,700も獲得しています。 SWRはライブラリ名で、stale-while-revalidateというRFC 5861で策定されたキャッシュ戦略の略称です。このSWRがデータ取得の扱いをラクにしてくれて最高なのです。 React開発者が嬉しいuseSWRの書き心地 useSWRは外部APIからのデータ取得、ローディング状態、エラーが発生した時をシンプルに記述できます。これがあらゆるReact開発者にとって（というか、ReactでAPIにリクエストを頻繁に送るアプリケーション
React18 設計とコードレビューの観点
はじめに 最近チームに React 18 を布教することの多い osuzu です。 普段の業務で、ペアプロ時に設計意図を伝えたり、コードレビューで都度自分の意図を伝えたりしてきました。 今回、これまでのチーム開発の経験やドキュメントに目を通す中で、自分が良いと考えている設計やコードレビューの観点を言語化することが出来てきたので、筆を執ってみました。 この記事はコードレビューの観点をチーム内へ知見共有するために書きましたが、社内に閉じる必要もない内容のため、Zenn でオープンに公開することにしています。 設計部分はプロジェクト（チーム）に依存していることが多く参考にしにくい部分もあるかもしれませんが、この記事がコードレビューや設計ガイドラインのような形で少しでも参考になれば幸いです。 記事の対象外 コードレビューそのものの基準や観点は取り扱いません。下記記事など適宜参考に。 Google
atama plus の osuzu です。 atama plus では、これから段階的に Web ベースプロダクトのフロントエンド開発で React を用いて SPA(Single Page Application) へリプレイスしていきます。 参考: 技術課題のないプロダクトなんてものはない！Django→React リプレイスの意思決定に至る atama plus 流の軌跡 この記事では SPA の技術選定にあたって考えたことを共有します。 プロダクトについて 技術選定はプロダクトの置かれた状況によって意思決定が変わると考えているので、リプレイスするプロダクトについて補足します。 atama plus は塾などで利用可能な学習アプリ「atama＋」を提供していますが、一連のプロダクトの中に塾本部の方が管理のために用いる業務アプリがあります。 今回リプレイスするのはこちらの業務アプリで
SWRを使おうぜという話2022
はじめに 2021年1月に以下のような記事を書きました。 内容はVercel社のオープンソースプロジェクトの一つであるデータフェッチライブラリであるSWRの紹介で、記事内に間違いなどもあったにも関わらずたくさんの反響を頂きました。 2022年半ばとなった今でも「いいね」を頂いております。 しかし、内容は2021年当時のものであり、ライブラリの仕様が少し変更となっておりますので、現在のSWRの仕様に合わせて新しく記事を書くことに致しました。 当記事の内容は「SWRを使おうぜという話」のシナリオに沿っての再掲と致します。 最後までどうぞお付き合いください。 SWRとはなにか SWRは、クライアントJavaScriptからのデータ取得とそれに関連する操作を提供するReact Hooks群です。 通常、Reactを使用してAPIサーバーからのデータ取得を非同期で行う場合、useEffectとfet
スコープとライフタイムで考えるReact State再考
ReactはじめSPAのStateは大きく2種類、Local State・Global Stateの2種類でおおよそのStateの分類が可能であると考えていました。これに対し会社の先輩から意見をもらって、以下2点に気づきました。 Global Stateには大きく、Client StateとServer Stateの2つがある Stateにはライフタイム（生存期間）が存在し、Client Stateにはスコープ的Globalと時間的Globalの2つが含まれている これらを意識すると、自分はStateの実装を結構感覚的にやってしまっていたなと気づいたので、Stateの分類について改めてまとめてみようと思います。Reactで何かしらのStateを実装する時に、本稿の分類が実装の参考になれば幸いです。 スコープによるStateの分類 まずこれまで自分が認識してたスコープにおけるStateの分類
TL;DR TanStack Query や SWR のようなデータ取得ライブラリは、難しいとされる Server State 管理を簡単にします。ユーザビリティやコンポーネント設計の品質も向上させます。導入する際にはいくつか注意する点があります。 （かなり長くなってしまったため、目次や目に留まった箇所だけ読むのも良いかと思います） スコープ この記事は Client Side Rendering(CSR) の SPA を対象とします。筆者（の業務）の関心や要求が少ないため、SSR や ISR はこの記事の議論では対象にしません[1]。読み込みパフォーマンスについても要求は控えめです。 利点や議論は特定の UI ライブラリ・フレームワークに限りませんが、筆者が慣れている React を使って説明します。 予備知識 React の State について この記事では、React の Stat
Next.js（SG） + SWR + Recoil + TypeScript でAPIグルメ検索（自動更新機能付き）
私はこうして文章を書いていますが、去年書いた文章はすべて不満であり、いま書いている文章も、また来年見れば不満でありましょう。それが進歩の証拠だと思うなら楽天的な話であって、不満のうちに停滞し、不満のうちに退歩することもあるのは、自分の顔が見えない人間の宿命でもあります。自分の文章の好みもさまざまに変化して行きますが、かならずしも悪い好みから良い好みに変化してゆくとも言いきれません。それでもなおかつ現在の自分自身にとって一番納得のゆく文章を書くことが大切なのであります。 ―― 三島由紀夫『文章読本-新装版』 (中公文庫) p.195 制作したもの。 API を用い、グルメ検索ページを作ります。 使用する API は、リクルート社のホットペッパーグルメ グルメサーチ API です[1]。 主な技術構成は、 Next.js / Static Generation SWR[2] Recoil Ty
はじめに 2か月前に「SWRを使おうぜという話」という記事を書きました。 Vercel謹製のSWRの便利さや導入の簡単さについて語りました。 そしてそれに感動を覚えたらとにかく使いたくなります。 だって既存のプロジェクトに導入するのも簡単だから（！） Firestore サーバーレスでのアプリケーションやデータをほとんど持たないwebサイトを作成するときは、私はfirebaseのFirestore(GCP)をよく利用します。 これもまたSWRなどと同じくとても簡単に導入できるので、各方面に推奨しております。 しかしFirestoreでの辛い点は、データの取得や更新に必要な手数の多さです。 通常の記載は下記。（※Typescriptを使用しております。） 投稿一つ型チェックするのにこのコーディング量！ type Categories = "ブログ" | "ニュース"; type Post =
import useSWR from 'swr' function Profile() { const { data, error, isLoading } = useSWR('/api/user', fetcher) if (error) return <div>failed to load</div> if (isLoading) return <div>loading...</div> return <div>hello {data.name}!</div> } この例では、useSWR フックは key 文字列と fetcher 関数を受け取ります。 key はデータの一意な識別子（通常は API の URL）で、fetcher に渡されます。 fetcher はデータを返す任意の非同期関数で、ネイティブの fetch や Axios のようなツールを使うことができます。 このフッ
import useSWR from 'swr' function Profile() { const { data, error, isLoading } = useSWR('/api/user', fetcher) if (error) return <div>failed to load</div> if (isLoading) return <div>loading...</div> return <div>hello {data.name}!</div> } In this example, the useSWR hook accepts a key string and a fetcher function. key is a unique identifier of the data (normally the API URL) and will be passed to f
Why I Stopped Using Redux
Redux was a revolutionary technology in the React ecosystem. It enabled us to have a global store with immutable data and fixed the issue of prop-drilling in our component tree. For sharing immutable data across an application, it continues to be an excellent tool that scales really well. But why do we need a global store in the first place? Are our frontend applications really that complex or are
SWR is a React Hooks library for data fetching. The name “SWR” is derived from stale-while-revalidate, a cache invalidation strategy popularized by HTTP RFC 5861. SWR first returns the data from cache (stale), then sends the request (revalidate), and finally comes with the up-to-date data again. With just one hook, you can significantly simplify the data fetching logic in your project. And it also
「フロントエンド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
Announcing SWR 2.0 – SWR
We are thrilled to announce the release of SWR 2.0, the popular React data-fetching library that enables components to fetch, cache, and mutate data and keeps the UI up-to-date with changes in that data over time. This new version comes packed with improvements and new features, such as new mutation APIs, improved optimistic UI capabilities, new DevTools, and better support for concurrent renderin
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
Announcing SWR 1.0 – SWR
Almost 2 years ago we open sourced (opens in a new tab) SWR, the tiny data-fetching React library that people love. Today we are reaching another milestone: the 1.0 version of SWR! What’s New Smaller Size Performance is one of the most important features of SWR. In 1.0, we made the library significantly smaller without removing any existing features: 41% smaller core (24% smaller when gzipped, 3.9
リモートのデータ取得のためのフックライブラリの 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-
対象読者 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 を 状態管理 として活用しているよという話
対象の読者 react の状態管理ライブラリ選定をしている方 SWR + Context API を使って状態管理を実現している方 結論 全て SWR で完結すると考えることが少なくなるので楽 SWR とは 日本語でも書かれているので分かりやすいです。 簡単にいうと SWR は データ取得のための React Hooks ライブラリ(公式サイトからそのまま引用)です。 今回のタイトルにある 状態管理は、アプリケーションレベルで管理される state と定義します。 すなわち特定のコンポーネントに限らず Global state として複数のコンポーネントから参照させたい値を保持させることも可能です。 SWR はデータ取得のためのライブラリでは...? あまり知られていないですが、SWR を状態管理としても使うことが可能です。[1] ドキュメントに記載されている箇所は確認できませんでしたが、
const { isLoading, error, data } = useQuery('repoData', () => fetch('https://api.github.com/repos/tannerlinsley/react-query').then(res => res.json() ) ) 一見、ほとんど一緒じゃん、となるが、SWRは「キーをfetcheの実行するためのパラメータ」になっている。 一方、react-queryは「キーと実行APIは独立している」。これはイメージとしてReduxのActionなどのconstantのような印象を受ける APIの違い Core API RQ : https://react-query.tanstack.com/docs/api SWR https://swr.vercel.app/docs/options#parameters これ
useSWR で作る Form 画面の備忘録
管理画面のような CRUD 中心のプロダクトでは Form と CSR をよく利用します。SWR は開発体験に優れたライブラリですが、Form に利用する場合注意点があるので、備忘録として共有します（広義の SWR と紛わない様に、タイトルはuseSWRとしました） 視覚的安定性とキャッシュ はじめに、SWR や React Query を利用するモチベーションについて言及します。SWR は一意のキーに紐づいたキャッシュが無い場合、loading fallback を表示します。fallback 表示はたとえ一瞬であっても「チカっ」とした表示になるため「スムーズではない印象」を利用者に与えてしまいます。しかし SWR や React Query は有キャッシュ時は fallback を SKIP するため、ユーザー操作を妨げずに視覚的安定性を提供することができます。 このメリットは、反復画
SWR 2.0 の発表 – SWR
本日、SWR 2.0 のリリースを発表できることに興奮しています！この新しいバージョンには、新しいミューテーション API や楽観的更新パターンに対する改善、DevTools、React の並行処理機能のサポートといった多くの改善と新しい機能が含まれています。このリリースを可能にしてくれた全てのコントリビュータとメンテナに感謝しています。 ミューテーションと楽観的 UI 更新 useSWRMutation ミューテーションはデータフェッチングの重要な要素の一つです。ミューテーションはローカルとリモートのデータそれぞれの更新を可能にします。既存の mutate API は、リソースの再検証及び手動による更新をサポートしています。SWR 2.0 では、useSWRMutation という新しいフックは宣言的な API でよりシンプルにリモートのデータ更新を可能にします。このフックを使いミューテ
SWR で SQL 発行量を節約する
最近 ORM の prisma を触る機会があり「フロントの設計次第で SQL 発行量が結構変わるなぁ」と改めて感じたのでメモ書きです（prisma に限らず、API 設計の際に考察ポイントになる内容です）。本稿では、次の様なアプリケーションを Next.js + prisma で実装するものとして話をすすめます。 著者・カテゴリーが登録できる 本を登録できる 本には、登録ずみの著者が 1 名設定できる 本には、登録ずみのカテゴリーが複数設定できる ユーザー認証が必要で SSG は想定していない タイトルのSWRは、こちらのライブラリを指します。 schema 定義 以下、雑にスキーマを定義します。Author・Category が親テーブル、Book が子テーブルです。 model Author { id Int @id @default(autoincrement()) created
SWRはローカルの状態管理としても使える
SWRとは SWRとはReactのためのデータフェッチライブラリです。 詳しい説明は省略しますが、リモートのデータ取得のためのキャッシュ機構を提供するライブラリとして知られています。 この記事では、そんなSWRが実はローカルの状態管理にも使用できることを紹介します。
react hooksの登場とある程度の枯れ具合を見せてきて、益々利用する機会が増えているReact。 最近はreduxを採用する/しないで議論が白熱することが多くなってきていますが、今回はreduxを採用せずとも、ある程度のアプリケーションなら作れる選択肢の一つを紹介させていただきます。 初投稿なので、読みづらかったらスンマセン。 zeit製のライブラリ swr 今回の主役はこのswr。 reactのSSRフレームワークであるnextjsやPaaSのNowなどのを開発・運用しているzeitから最近登場したライブラリです。 このライブラリのREADMEの頭には、以下のように紹介されています。 SWR is a React Hooks library for remote data fetching. そう、つまり、data fetchをhooksベースで記述するためのライブラリです。 どん
Next.jsでフロントエンドを作っているプロジェクトにSWRを導入した際に「SWRかgetServerSidePropsのどちらでデータ取得をすればいいのか迷う」みたいな意見があったので、チームで方針を作ったときに考えたことの話。 フロントエンドの構成については、バックエンドのREST APIを叩きに行ってデータを取得・更新する至って普通の構成。ただユーザーの認証をする必要があり、sessionの有無を見つつページの出し分けとかAPIの取得をする形になっている。認証部分はAWSのCognitoでクライアントにはnext-authを使用した。 データ取得の方針 データ取得・更新について、基本的にSWRを使用する方針にした。SWRについては周知の通りキャッシュ機構で高速にデータの表示ができるので使わない手は無いと思う。 また、next-authのuseSessionを使ってsession(に
【 Next.js 】Static Generation + useSWR で、データ更新、最新のデータ表示を可能にする。
「四間飛車の極意を一言でいうと何でしょう？」 ファンの質問に私はいつもこう答えます。 「相手の力を利用して、投げる、でしょうか。」 ―― 将棋棋士 藤井猛『四間飛車を指しこなす本〈1〉』（2000/3/24）河出書房新社 実現したいコンセプト Next.js の Static Generation (略して SG[1]。以前でいうところのSSG(Static Site Generation))を利用し、ハイパフォーマンスなページを作りたい。 （Google Lighthouse で100点を取りたい。） Static Generation を利用しつつ、ページのデータを更新したい。 特に、SSG と呼ばれていた時代、更新が多いページは、SSG には適さないと言われていた。 ページを表示したとき、最新のデータが表示されるようにしたい。 => データの強整合性(Strong Consisten
SWRと状態管理
VSCodeでのDatabricks開発もお勧めしたい/I would also recommend Databricks development with VSCode.
CloudFront と S3 の階層化 TTL でシングルページアプリケーション (SPA) をホストする | Amazon Web Services
Amazon Web Services ブログ CloudFront と S3 の階層化 TTL でシングルページアプリケーション (SPA) をホストする 数多くのお客様がシングルページアプリケーション(SPA) のデプロイのために Amazon CloudFront と Amazon Simple Storage Service (Amazon S3) を利用しています。ウェブアプリケーションは React、 Angular、 Vue 等のフレームワークで実装されています。これら SPA を開発しているチームは、一見相反するようにも思える以下のような要件を持っていることが多いです。 ウェブアプリケーションをダウンロードする時のユーザーが体感する遅延をできるだけ小さくしたい。そのために、ユーザーの近くにある CloudFront のエッジロケーションにウェブアプリケーションをキャッシュさ
Shared Hook State with SWRMay 09, 2020SWR is a React hook for data fetching that features a cache for requests. This is generally used to share the response from API calls and deduplicate requests, but SWR is flexible enough to support another use case: shared hook state. 1 Let's look at an example of a useUsername hook: const useUsername = () => { return useState('') } const UsernameInput = () =>
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
React周りのいつかお世話になる記事たち（随時更新）
「3種類」で管理するReactのState戦略
【脱Redux】SWRやReact Queryを使った状態管理戦略
Design Doc for react-boilerplate-2022
React SPA の技術選定で考えたこと（atama plus のケーススタディ）
データ取得ライブラリを SPA に導入するとなぜ嬉しいのか
SWRで爆死を避ける。firebase Cloud FirestoreとNext.js。
データ取得のための React Hooks ライブラリ – SWR
React Hooks for Data Fetching – SWR
GitHub - vercel/swr: React Hooks for Data Fetching
ReactのSuspenseを使った非同期処理のエラーハンドリング
React Query を使っていて気になった SWR とのいくつかの違い | DevelopersIO
React Hooks向けライブラリSWRとは？ 通信とキャッシュ管理を簡便に
SWRとReact Queryどっち使おうか検討したメモ
zeit製のswrがすごい - Qiita
それSWRじゃなくてgetServerSidePropsでいいよねっていう場面の話
Shared Hook State with SWR
life-insight.hatenadiary.com
day-mitama777.hatenablog.jp
kuroneko356.hatenablog.com
robeat48.hatenablog.com
note.com/tsukasa_yamato
toyokeizai.net