Next.js の fetchCache を考える
Next.js App Router は global のfetch関数に patch をあてており、自動でデータ取得が最適化されるように設計されています。そのうちの一つが、取得したデータをキャッシュし、再利用する最適化です。キャッシュされた取得データは、必要に応じて任意のタイミングで Revalidate（データ再取得・キャッシュ更新）が可能です。本稿はこのfetch関数を経由してキャッシュされる「fetchCache」について、どのように向き合うべきか考察したメモです。 検証留意点 はじめに、筆者が検証にあたり留意した点を書いていきます。本稿を読んでみて「自分でも検証してみたい！」となった方は、参考にしていただければと思います。 【1】取得データがキャッシュされるタイミング タイミングは２通りあります。 ビルド時: next buildで Next.js アプリをビルドした時 リクエス
React Hook Form でも再描画に気を付ける
React Hook Form を使うと、useStateを使う制御フォームにありがちな「頻繁な再描画」を手短かに防ぐことができます。しかし、使い方によっては、その利点を崩してしまうことがあります。それが、useFormの戻り値に含まれるwatchの使用です。 watch は頻繁な再描画の原因になる 次のコンポーネントは、よくあるサインアップフォームです。emailに入力された文字数をカウントし、インタラクティブに「何文字入力されているか」を表示します。watchは、このような値の購読に利用できる API です。しかしコメントにあるとおり、emailに文字が入力されるたび、このフォーム全体が再描画されてしまします。これは、多くの要素を含むコンポーネントで避けたい実装例です。 const defaultValues: Form = { email: "", password: "", };
React コンポーネントの「制御・非制御」を意識しない方法
React でフォームを作るとき「制御・非制御」コンポーネントに関する知識は必須です。デザインシステムを作成するにあたり、どちらを採用するか検討されたこともあるかと思います。 「制御・非制御」コンポーネントの差分を一言でまとめると、次のとおりです。 制御コンポーネントはライブラリ（React）が「入力要素の状態」を管理 非制御コンポーネントは「入力要素の状態」を DOM 自身が保持 「制御・非制御」コンポーネントと Form ライブラリ React Hook Form は、非制御コンポーネントを使うことで、少ないコード量で高パフォーマンスの Form 実装が実現できる人気のライブラリです。「非制御コンポーネント」として作成された<Checkbox>コンポーネントの例を見てみましょう。次の方法で<input type="checkbox" name="test" />がレンダリングされ、Fo
私のフロントエンドディレクトリ構成・テスト観点 2022
近日連投していた Next.js 記事のサンプルコードを公開しました。このサンプルコードを元に、私のフロントエンドディレクトリ構成・テスト観点を紹介します（あくまで執筆現在の脳内アウトプットになりますのでご了承ください） フロントエンドディレクトリ構成の事情 タイトルの「フロントエンドディレクトリ構成」をさす「Components」のディレクトリ構成は、いつも悩みのタネです。このモジュールシステムは「デザインシステム観点・アクセシビリティ観点・フロントエンド実装観点」の 3 つの観点が混在するため事情が複雑です。どうせ作るのなら「デザイナー・フロントエンド」どちらの開発基盤にもなりえる、盤石なモジュールシステムを目指したいですよね。 "AtomicDesign やめました"という声をたまに聞くのですが「デザインシステム的に捨てていいの？」と思うこともあるので、とくに要望がなければ、筆者は「
Next.js と MSW 高階関数
本稿では Next.js アプリ設計と同時に検討しておきたい、API Mocking の設計（MSW の活用テクニック）を紹介していきます。※ 解説のなかで jest を使いますが、ここは特別こだわりがあるわけではありません。 MSW で表現する API 群 MSW は Next.js アプリのローカル開発に役立ちます。任意の API を任意のレイヤーで、個別にインターセプト可能です。 「ブラウザー → API Routes」間でインターセプト 「API Routes → API 群」間でインターセプト 「getServerSideProps → API 群」間でインターセプト また、自動テストに利用でき、フロントエンドの単体・結合テストが書きやすくなります。同一プロセスでサーバーレスポンスをモックするため、外部プロセスに依存しない、高速な自動テストを回すことができます。 MSW 高階関数
a11yとテストを同時に改善する話
これまで、a11y 改善・テスト拡充にあたり「どのように改善すべきか？どのように書くべきか？」という点がハードルだと感じていました。Chrome で a11y tree を確認するには、dev tools の隅の隅をつつく必要があり、あまり体験の良いものではなく、気に入ったエクステンションもありませんでした。 Testing Library は「誰もがアクセスできるクエリー」を優先的に使用することを推奨していますが、アプリケーションがはじめから a11y に考慮された作りになっているとは限りません。これらの背景から「data-testid」のような、テスト向け属性に頼るワークアラウンドで乗り切ることも少なくありませんでした。 Full page accessibility tree 今年 1 月にリリースされたChrome98 の新機能として「Full page accessibility
パフォーマンス観点でみる Next.js の getLayout
Next.js は、ページ単位でデータ取得・レンダリング手法を選べる事が利点です。そして、ページ単位でチャンクファイルが生成されるため、パフォーマンスに貢献します。 これはあるページに来訪した際、必要最低限のファイルロードで済むということです。ファイルロードの時間は、ユーザーが操作開始できるまでの時間（TTI）に繋がります。Next.js でコーディングしていれば意識せずとも、ファイル分割の最適化は適用されます。 これだけでも SPA 構築に Next.js を選ぶ理由になりますが、ファイル分割は実装次第で、良くも悪くもなることを紹介していきます。 First Load JS shared by all _appは、どのページにアクセス・ナビゲーションしても、必ず通過します。そのため、_appに関連するファイルは 「First Load JS shared by all」 として、全てのペ
React18 の useId で a11y対応する
aria-controlsやaria-errormessage・aria-labelledbyは、一意の ID 属性で 2 つの異なる要素を紐づける必要があります。 エラー文言付き Textbox 例として、以下の様な「errorMessageを与えた時にエラー表示する」Textbox コンポーネントを見ていきます。 <Textbox title="お名前" inputProps={...register("name")} errorMessage="正しく入力してください" /> 対象となるのは「input 要素・エラー文言要素」です。この 2 者を紐づけるためには、エラー文言要素を指す ID 属性が必要です（aria-errormessageとして input 要素に指定）これを達成するには、props で ID 指定するか、内部的に ID を生成する必要があります。前者は面倒なので、
Testing Next.js - getServerSideProps & API Routes -
Next.js の getServerSideProps & API Routes テスト手法についてまとめました。getServerSidePorps & API Routes に関するテストは「Cypress・Playwright」を利用することが多いと思いますが、本稿は Jest 単体テストの紹介です。以下はテストに使用するエコシステム一式です（Jest 等は略） msw node-mocks-http next-test-api-route-handler testing-library 1.pageExtensions を設定する 本題に入る前に、pageExtensions を next.config.jsに設定します。pageExtensions はpagesに含まれるファイルのうち、指定の拡張子をもつファイルが「Page・API 実装ファイルである」ことを指定するものです。
React.ComponentProps 型を積極的に使おう
Atomic Design でいう Atoms に相当する、汎用コンポーネントについての小話です。次の様に Props 型定義を用意し、解説している記事をよく見かけます。<input />タグを使わずコンポーネント化している理由は style を施すためかと思いますが、このコンポーネントが受け取れる Props は限定的で、メンテナンスコストが高いためお勧めできません。 type Props = { value: string; onChange?: React.ChangeEventHandler<HTMLInputElement> onBlur?: React.FocusEventHandler<HTMLInputElement> } export const Input = ({ value, onChange, onBlur }: Props) => ( <input value=
テスト優先度をあげたくなる実話 - フロントエンド版 -
Storybook・テストに関して「メンテナンス工数に見合うだけのメリットがあるか？」という議論を、経験したことはないでしょうか。フロントエンドは、とにかく動くものを作ることが優先され、Storybook・テストが二の次になっている現場も少なくないと思います。 限りある工数を割きチームで取り組むものですから、導入するためには「どういったメリットがあるのか？」という具体的な例をチームに示す必要があります。これは今年、筆者が体験した実メリットのお話です。導入を躊躇している現場にむけ、参考になればと思い書きました。 【Storybook】不要な Global CSS を削除できた きちんとコンポーネント設計され、コンポーネントに閉じた指定をしていたとしても、どこかに必ず Global な CSS があると思います。何かしらの資材を受け継ぎ立ち上げたプロジェクトに関しては、Global な CSS
Next.js の Error を丁寧に扱う
Next.js には組み込みのエラーフォールバック機構が存在します。pages/404.tsxとpages/500.tsx、Unhandled Error を捉えるpages/_error.tsxが組み込みフォールバックです。https://nextjs.org/docs/advanced-features/custom-error-page 実アプリケーションにおいてはこれだけでは不十分なケースが多く、意図的なもの・そうでないものをハンドリングしログ収集に繋げるなど、きちんとエラー設計をしたいところです。 TypeScript 4.4 で try catch の推論が変更になった 話が少しそれますが、TypeScript 4.4 で try catch 文の catch 引数errの推論がanyからunknownに変更になりました。この変更はuseUnknownInCatchVariab
openapi-generator-cli による TypeScript 型定義
openapi-generator-cli を利用すると、OpenAPI 定義から TypeScript で利用可能なアセットを生成することができます。しかし最適な成果物を得るためには、OpenAPI 定義自体に少し工夫が必要で、一筋縄にはいかないことがあります。 本稿及びサンプルリポジトリでは、openapi-generator-cli と TypeScript 4.2 の新機能を活用したアプローチを紹介します。 課題点の確認 OpenAPI 定義にあたりresponsesフィールドのschemaに対し、インラインで定義を追加することが多いのではないでしょうか？OpenAPI を定義する GUI 「Stoplight Studio」 などでは、このインラインスキーマ定義が直感的で使いやすく、yaml を直接編集しなくても良いなど、開発に重宝します。 responses: "200": d
atoms で活用したい CSS 隣接セレクタ
CSS 隣接セレクタ（隣接兄弟結合子）を活用すると、JavaScript のみで制御するよりもスマートな atoms を作ることができます。また、JavaScript の処理を削減することが出来ます。 【本稿サンプル】https://github.com/takefumi-yoshii/atoms-example 装飾は「状態管理」に依存させない 以下は関連記事をベースに作った Component です。ref forwarding が何故必要かは、そちらの記事を参照してください。 label 要素に囲まれており、状態をもたない input 要素を保持しているが、type は決まっていない Props で「３種の形状切り替え」が可能（"checkbox" | "radio" | "toggle"） import React from "react"; import styles from
atoms の「制御・非制御」をどう作るのか
本稿では React で atoms を作る際「制御・非制御」どちら前程に作るべきか？という課題についてを考察します。 「制御・非制御」は atoms では決定しない なぜ決定しないのかは「ライブラリ選定に縛られないため」につきます。Form 関連ライブラリはたくさん選択肢がありますが、この選定が atom に影響するのはあまり良いパターンではありません。 「制御・非制御」は atoms では決定しないといっても、正確には以下の「A・B」のうち 「A」で決定しない という意味です。以下「A・B」の様にきちんと分けて構成することで「A」は「制御・非制御」に囚われず、再利用することが出来ます。 A. 【"style"決定層】CSS のみが適用された element 集 B. 【"制御・非制御"決定層】A を用いて、再度小さい atom を構築する CSS in JS 以外での定義 CSS in
React.Context で作る GlobalUI Custom Hooks
GlobalUI を、React.Context を利用して作る TIPS です。どの Component からも利用しやすい様に Custom Hooks を経由します。何かを更新した際、画面上部に通知を表示する（Notification）よくあるサンプルを元に解説します。（↓ の画像の様なもの） Custom Hooks 利用例 Notification を呼び出す Component は次の様なコードになります。showNotification関数に任意の文字列を与え表示する、というシンプルな作りです。 export const Example = () => { const { showNotification } = useNotificationDispatch(); const handleClick = () => { showNotification("更新しました");
Next.js が CSS Modules を推奨する真相に迫りたい
Next.js 9.2 から CSS Modules がビルトインサポート対象になった。 CSS最適化に関して、組み込みサポートのレールから逸れると、ページ単位で最適化された静的CSSの生成不全に陥る。少しでもパフォーマンスの良い Next.js App を構築したいのなら、CSS Modules 一択というのが現状で、CSS in JS に慣れ親しんだ身からすると正直辛い現実だ。 CSS in JS よりも CSS Modules の方が、ロードタイム・ランタイムともに、パフォーマンス面で有利なことは知られている。こちらのベンチマークテストが参考になる。 しかし、本来であるなら皆 CSS in JS を使いたいのではないか。あえてレガシーな CSS Modules 推奨とする理由は、CSS という難儀な仕組みを乗り越えるため、技術的に「そうせざるを得ない」理由が他にもあるのではないか。真
Next.js の状態管理 2020
Next.js といえば、SSG（JAMstack）が最近は特に話題ですね。1年前まではgetInitialPropsを用いて、どう SSR するのかという事が話題の中心でした。Next.js 9.3 以降、SSR をする際にはgetInitialPropsではなくgetServerSidePropsを使用することを推奨すると記載されています。（そして、getInitialPropsを使用することで自動最適化が無効となってしまう旨も）getStaticPropsやgetServerSidePropsを利用することで、私たちは SSG・SSR をページ単位で切り替えることができます。 「SSG・SSR」が共存する可能性がある場合、SSR にはgetServerSidePropsを利用することになります。この変化による影響範囲は多大で、状態管理とデータフェッチについて、再考する必要がでてきまし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Next.js の「next start・next dev」挙動差分一覧
Next.js と 非同期分割 CSS の悲劇