Next.js の App Router を中心に解説した書籍を執筆しました。「実践 Next.js —— App Router で進化する Web アプリ開発」という本です（3/16 刊行）。本稿では書籍の概要と、App Router が何を解決するのかについて紹介します。 書籍の概要 書籍で解説しているサンプルコードは、public リポジトリで既に公開しています。前半、第 1 章〜第 4 章では App Router の基礎を抑えるための練習用リポジトリを使用します。後半、第 5 章〜第 10 章では、写真を投稿する SNS「Photo Share」という架空アプリの実践的リポジトリを使用します。 第 1 章：Next.js の基礎 第 2 章：Server Component とレンダリング 第 3 章：App Router の規約 第 4 章：Route Handler 第 5

本稿は Next.js で今試せる React canary の機能「useFormState」に関する記事です。Server Action を使用すると、API Client を使用せずにブラウザから直接サーバーサイドの関数を実行できます。Server Action のメリットは以下のものが挙がります。 API Client が不要になる ハイドレーションを待たずに反応できる Progressive Enhancement を維持できる useFormState の話の前に、Server Action について少し触れていきます。 Server Action だけではない「Client Action」とは？ 「Server Action」というワードを知っている方は多いと思いますが「Client Action」はまだ馴染みのないワードかもしれません。React、Next.js いずれも公

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=

この<Icon />コンポーネントを使用すると、以下キャプチャのようになります。 UI ライブラリから提供されているものを使用する選択肢もありますが、デザイナーが用意した SVG を使用する場合は自作する必要があります。自作<Icon />コンポーネントのフォルダ構成は、概ね以下のようになるでしょう。 SVG Icon Component をどう作るか アイコン画像を背景画像ではなく SVG にする理由は「塗り色」を動的に変更したいためです。新色を追加するとき、全種のアイコン画像を追加するのは大変です。SVG であれば、要素に対しpath { fill: #ff0; }のように CSS 指定をすることで動的に塗り色を変更できるため、このようなケースでは「インラインレンダリング」が選択できます。インラインレンダリングであれば、塗り色だけでなくサイズも動的に変更できます。 ただし、インラインレ

Next.js App Router は global のfetch関数に patch をあてており、自動でデータ取得が最適化されるように設計されています。そのうちの一つが、取得したデータをキャッシュし、再利用する最適化です。キャッシュされた取得データは、必要に応じて任意のタイミングで Revalidate（データ再取得・キャッシュ更新）が可能です。本稿はこのfetch関数を経由してキャッシュされる「fetchCache」について、どのように向き合うべきか考察したメモです。 検証留意点 はじめに、筆者が検証にあたり留意した点を書いていきます。本稿を読んでみて「自分でも検証してみたい！」となった方は、参考にしていただければと思います。 【1】取得データがキャッシュされるタイミング タイミングは２通りあります。 ビルド時: next buildで Next.js アプリをビルドした時 リクエス

App Router で API Routes 相当の実装を施すには Route Handlers を使用します。Next.js に限らず React 実装では今後 fetch を使用したいというニーズが多くなると思うのですが、fetch は型推論がほとんどダメです。また、Client/Server で実装が散らばっているため、リクエスト・レスポンスのずれが生じる懸念があります。Route Handlers でも tRPC のような実装ができればと考え、それっぽい実装ができたので紹介します。 愚直に実装する場合 「書籍販売するサイトの詳細ページで、クリックログを送信する機能を実装する」と仮定して、詳細をみていきましょう。まず、クライアント側はこのようになります。ボタンコンポーネントを作成し、fetch を実行します。 "use client"; type Props = { bookId:

MSW はネットワークレベルでリクエストをインターセプトする、自動テストで便利なモックサーバーです。過去記事でも紹介したとおり、スパイ（モック関数）をネットワークレベルに忍ばせることが可能です。実際に WebAPI が呼ばれた時の Payload の検証は、Jest 組み込みのモック機能では実現できない領域です。本稿は「WebAPI リグレッションテスト」を実施するための、MSW 活用方法を解説します。記事で使用しているサンプルコードはこちら。 課題の概要 Web アプリケーションページのほとんどは「1.UI を表示し／2.入力操作し／3.WebAPI 通信し／4.通信後処理を行う」という一連処理が責務です。このようなページに書かれるテストは、WebAPI 通信前後に集中しがちです。MSW を使用すると、以下の図の様に「送信後処理」まで到達可能なため、例えば「WebAPI レスポンスが返っ

昨年から執筆を続けていた書籍が 4/24 に刊行します。「フロントエンド開発のためのテスト入門」という本です。 書籍ならではのテストコード解説を目指して 次の投票結果は、書籍企画時に持ち込んだ筆者のツイートです。フロントエンドテストに関していえば、8 割近くの方が何かしら不安や不足を感じている、という結果になりました。 不安や不足の原因は様々なものがあるかと思います。そのうち、筆者が着目したのは「テスト手法の豊富さ」です。「単体テスト・結合テスト・E2E テスト、何をどれほど書けばよいのか？」という疑問は、フロントエンドに限らず、はじめて自動テストに取り組まれる方が通る関門ではないでしょうか。 自動テストを書くには「テスト対象」を明確にしたうえで、テスト対象に適したテストコードを書く必要があります。本書は、現場で書かれるものに近い「テスト対象 = アプリケーションコード」をサンプルとして用

tRPC は Next.js プロジェクトの生産性を向上させるライブラリです。サーバー側定義の型推論が API Client にダイレクトに伝搬するだけでなく、Zod スキーマによる入力値制約が施せます。そのため、Client ⇄ API Routes 間の疎通がEnd-to-end typesafeになる、便利なライブラリです。 tRPC と MSW の統合要点 筆者はテスト・Storybook をコミットする際に MSW をよく利用しています。次の様に任意の URL リクエストをインターセプトして、スタブを返却できます。 import { rest } from 'msw' export const handlers = [ rest.get('https://api.github.com/user/:login', (req, res, ctx) => { return res(ct

本年は Next.js + バリデーションライブラリの Zod をよく利用し、Zenn でもいくつかの関連記事を投稿しました。本稿では、この組み合わせならではの TIPS を紹介します。記事で紹介するサンプルは以下に置いています。 リクエスト検証に便利な Zod Next.js で getServerSideProps を使用すると、リクエスト検証をサーバーサイドで行えます。例えばセッションに保持している値の検証はバリデーションライブラリの Zod を使用して、次のようなコードで実現できます。 export const userSchema = z.object({ name: z.string(), email: z.string(), }); export const getServerSideProps = async (ctx) => { const sess = await ge

Next.js 13 新機能の App ディレクトリの勉強がてら、結合テストをどう書いていったらよいか考察しました。参照している公式ドキュメントが beta 版なのはもちろん、App ディレクトリそのものが beta 版なので、実運用には使えるものではないと思うので予めご了承ください。一応こんな感じで書けそう、という話です。 結合テストの準備 本稿が指す結合テストとは、App ディレクトリのルートセグメントを構成する、特別なファイル（Special Files）が、与えた状態に応じてどのように表示されるかを検証するテストを指します。 ルートが外部から受ける要因として大きいものが、URL に含まれるクエリパラメーター・パスパラメーターです。コンポーネントは、これらの値を参照して API サーバーにリクエストしたり、ORM ライブラリからクエリーを発行したりなど、コンポーネント表示に必要な処理

バリデーションライブラリである Zod を、Next.js で活用する TIPS の紹介です。筆者が Zod を知り・使い始めたのは、React Hook Form のリゾルバーがきっかけです。ブラウザでバリデーションを行うので、不正な入力値検証を API リクエストが発生する前に実行できます。 この Zod はフロントだけではなく、サーバープロセスでも使用できます。例えば、tRPC・Zodiosなどに見られるように、サーバーへのリクエスト（入力値）を検証しつつ型推論も解決してくれるソリューションとして注目されています。 Next.js API Routes に Zod を組み込む Next.js には REST API の実装手段として、API Routes が提供されています。しかし、reqに含まれる入力値検証は自前で用意する必要があります。この入力値検証に Zod を使用されている方

先日、こちらの記事「Tailwind 考」を発端に、Tailwind CSS を愛用されている方達の間では「命名を考えなくてもよい」という点を、高く評価されているように感じました。実際、stylede-components はコンポーネント毎に命名するのが一般的ですし、CSS Modules も書き方によっては、セレクター名称をたくさん考えなければいけません。 職場で働く同僚の間でも、要素に直接スタイルをあてない書き方だと「命名規則で迷いそう、ガイドラインが必要そう」という声を聞きます。普段 CSS Modules を利用している筆者ですが、コーディング時命名に迷うことはかなり稀です。「迷わないために何を基準にすべきか？」について、わたしが普段ヒントにしている点を紹介します。 UI コンポーネントを細分化する まずはじめに検討するのは、UI コンポーネントの細分化です。UI コンポーネント

単体テストを書く時、モジュール間の関連を検証するため、一部のモジュールをモックする必要が出てくることがあります。モックは様々な手法がありますが、書き方によって、メンテナンス性やテストの可読性が変わります。一般的に行われるモック手法を確認しつつ、よりリーダブルなテストを書く方法を紹介します。 ログイン API を呼び出す Web API クライアント 今回紹介する、モック対象の Web API クライアントです。Native Fetch API を関数でラップした、自作の Web API クライアント（ログインするためのlogin関数）です。 export type Data = { redirectUrl: string; }; export type Input = { email: string; password: string; }; export async function l

React Hook Form を使うと、useStateを使う制御フォームにありがちな「頻繁な再描画」を手短かに防ぐことができます。しかし、使い方によっては、その利点を崩してしまうことがあります。それが、useFormの戻り値に含まれるwatchの使用です。 watch は頻繁な再描画の原因になる 次のコンポーネントは、よくあるサインアップフォームです。emailに入力された文字数をカウントし、インタラクティブに「何文字入力されているか」を表示します。watchは、このような値の購読に利用できる API です。しかしコメントにあるとおり、emailに文字が入力されるたび、このフォーム全体が再描画されてしまします。これは、多くの要素を含むコンポーネントで避けたい実装例です。 const defaultValues: Form = { email: "", password: "", };

React でフォームを作るとき「制御・非制御」コンポーネントに関する知識は必須です。デザインシステムを作成するにあたり、どちらを採用するか検討されたこともあるかと思います。 「制御・非制御」コンポーネントの差分を一言でまとめると、次のとおりです。 制御コンポーネントはライブラリ（React）が「入力要素の状態」を管理 非制御コンポーネントは「入力要素の状態」を DOM 自身が保持 「制御・非制御」コンポーネントと Form ライブラリ React Hook Form は、非制御コンポーネントを使うことで、少ないコード量で高パフォーマンスの Form 実装が実現できる人気のライブラリです。「非制御コンポーネント」として作成された<Checkbox>コンポーネントの例を見てみましょう。次の方法で<input type="checkbox" name="test" />がレンダリングされ、Fo

近日連投していた Next.js 記事のサンプルコードを公開しました。このサンプルコードを元に、私のフロントエンドディレクトリ構成・テスト観点を紹介します（あくまで執筆現在の脳内アウトプットになりますのでご了承ください） フロントエンドディレクトリ構成の事情 タイトルの「フロントエンドディレクトリ構成」をさす「Components」のディレクトリ構成は、いつも悩みのタネです。このモジュールシステムは「デザインシステム観点・アクセシビリティ観点・フロントエンド実装観点」の 3 つの観点が混在するため事情が複雑です。どうせ作るのなら「デザイナー・フロントエンド」どちらの開発基盤にもなりえる、盤石なモジュールシステムを目指したいですよね。 "AtomicDesign やめました"という声をたまに聞くのですが「デザインシステム的に捨てていいの？」と思うこともあるので、とくに要望がなければ、筆者は「

本稿では Next.js アプリ設計と同時に検討しておきたい、API Mocking の設計（MSW の活用テクニック）を紹介していきます。※ 解説のなかで jest を使いますが、ここは特別こだわりがあるわけではありません。 MSW で表現する API 群 MSW は Next.js アプリのローカル開発に役立ちます。任意の API を任意のレイヤーで、個別にインターセプト可能です。 「ブラウザー → API Routes」間でインターセプト 「API Routes → API 群」間でインターセプト 「getServerSideProps → API 群」間でインターセプト また、自動テストに利用でき、フロントエンドの単体・結合テストが書きやすくなります。同一プロセスでサーバーレスポンスをモックするため、外部プロセスに依存しない、高速な自動テストを回すことができます。 MSW 高階関数

これまで、a11y 改善・テスト拡充にあたり「どのように改善すべきか？どのように書くべきか？」という点がハードルだと感じていました。Chrome で a11y tree を確認するには、dev tools の隅の隅をつつく必要があり、あまり体験の良いものではなく、気に入ったエクステンションもありませんでした。 Testing Library は「誰もがアクセスできるクエリー」を優先的に使用することを推奨していますが、アプリケーションがはじめから a11y に考慮された作りになっているとは限りません。これらの背景から「data-testid」のような、テスト向け属性に頼るワークアラウンドで乗り切ることも少なくありませんでした。 Full page accessibility tree 今年 1 月にリリースされたChrome98 の新機能として「Full page accessibility

Next.js で開発をしていると、ドキュメントに書かれている通りに記述してもうまく動かず、実は「next build && next start しないと確認できないものだった」という事がしばしばあります。そこで、気づいた時雑多に放り込む場所があると良さそうと思い、スクラップを開きました。 どなたでも投稿大歓迎です。