ProviderタワーをRecoilに置き換える
ReactアプリケーションではProviderタワーがよく見られます。Providerタワーは、アプリの上の方で次のコードのように複数のProviderが積み重なっている状態のことです（一般的な呼称かどうかは知りません）。 const App: React.FC = () => { return ( <FooProvider> <BarProvider> <BazProvider> <MainContents /> </BazProvider> </BarProvider> </FooProvider> ); }; Providerは、コンテキストに対して値を供給する役割を担っており、コンポーネントツリー内でProviderより内側に配置されたコンポーネントからはそのコンテキストの値を参照することができます。コンテキストは、Reactにおいて外部ライブラリを使わずにステート管理（特にアプリ
フロントエンドのテストのモックには msw を使うのが最近の流行りらしい
皆様フロントエンドのテストを書いていらっしゃいますでしょうか？ フロントエンドのテストを書くときには API コールする処理を全てモックする必要があります。外部の API をコールする処理をテストに含めると API サーバーが落ちているなどの外部の要因によってテストが失敗してしまう可能性がありますし、テストを実行するたびに実際に API をコールしてしまうとサーバーに負荷がかかってしまうなど外部に対しても悪影響を与えてしまいます。 さて、従来のモックする手段としては Jest のモックを利用して axios や fetch などのモジュールをモック化する手法がよく使われていたかと思います。 最近のテスト手法として API コールをモックする際に Jest ではなく Mock Service Worker (以下 msw ）を使用する手法が注目されています。実施にどのように使用されているのか
データ取得のための React Hooks ライブラリ「SWR」をNext.jsで試してみた | DevelopersIO
こんにちは！DA(データアナリティクス)事業本部 サービスソリューション部の大高です。 Next.jsと同じチームによって作成されている、データ取得のための React Hooks ライブラリとして「SWR」というライブラリがあります。 今回はこのライブラリの一番基本の部分をNext.jsのプロジェクトで試してみたいと思います。 SWRとは 公式サイトにも以下のように記載されていますが「SWR」という名前はHTTPキャッシュ無効化戦略であるstale-while-revalidateに由来しています。 “SWR” という名前は、 HTTP RFC 5861 で提唱された HTTP キャッシュ無効化戦略である stale-while-revalidate に由来しています。 SWR は、まずキャッシュからデータを返し（stale）、次にフェッチリクエストを送り（revalidate）、最後に
Cloudflare Pages + Functions + Workers KV + vite + preactで簡単なページを作った
今回作ったページは下記。 https://haropuro-shuffle.pages.dev/ 元ネタ リポジトリ YuheiNakasaka/haropuro-shuffle 簡単なルーレットアプリ。ルーレットで出た結果をWorkers KVに保存。保存された文字を都度更新して表示(リアルタイムではない)。結果が1000件を超えるとクリアされる。 開発の流れ Workers KVの設定 vite + preactのアプリ開発 Cloudflare Pages/Functionsにデプロイ Workers KVの設定 Workers KVとは PagesやFunctionsから呼び出せるKey-Valuesストア。ここ見るとわかるけど容量制限など結構厳しいのでDBとして本格的に使える感じではない。 設定方法 まずGUIからだとWorkersのページからnamespace(database
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
