Next.js の Zod 活用術
本年は 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 結合テストに挑戦してみた
Next.js 13 新機能の App ディレクトリの勉強がてら、結合テストをどう書いていったらよいか考察しました。参照している公式ドキュメントが beta 版なのはもちろん、App ディレクトリそのものが beta 版なので、実運用には使えるものではないと思うので予めご了承ください。一応こんな感じで書けそう、という話です。 結合テストの準備 本稿が指す結合テストとは、App ディレクトリのルートセグメントを構成する、特別なファイル（Special Files）が、与えた状態に応じてどのように表示されるかを検証するテストを指します。 ルートが外部から受ける要因として大きいものが、URL に含まれるクエリパラメーター・パスパラメーターです。コンポーネントは、これらの値を参照して API サーバーにリクエストしたり、ORM ライブラリからクエリーを発行したりなど、コンポーネント表示に必要な処理
Next.js API Routes に Zod を組み込む
バリデーションライブラリである 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 を使用されている方
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
Next.js と MSW 高階関数
本稿では Next.js アプリ設計と同時に検討しておきたい、API Mocking の設計（MSW の活用テクニック）を紹介していきます。※ 解説のなかで jest を使いますが、ここは特別こだわりがあるわけではありません。 MSW で表現する API 群 MSW は Next.js アプリのローカル開発に役立ちます。任意の API を任意のレイヤーで、個別にインターセプト可能です。 「ブラウザー → API Routes」間でインターセプト 「API Routes → API 群」間でインターセプト 「getServerSideProps → API 群」間でインターセプト また、自動テストに利用でき、フロントエンドの単体・結合テストが書きやすくなります。同一プロセスでサーバーレスポンスをモックするため、外部プロセスに依存しない、高速な自動テストを回すことができます。 MSW 高階関数
Next.js に Service層 を導入する
本稿は、Next.js で「getServerSideProps や API Routes」を利用するアプリケーション向け内容になります。重厚な作りになるので、要件に適合する・しないはあると思いますので、あしからず。 Next.js は薄いフレームワーク Next.js は SPA 配信の最適化にフォーカスしており、Backend の機能面が十分とは言えません。pages の Page コンポーネントや API Routes は、controller としての機能を提供するのみです。ドキュメントを見てもわかるとおり、一連処理はあらかじめ middleware やラッパー関数を用意するのが常套手段かと思います。 NestJS にあるような Service 層が欲しい Node.js Backend フレームワークとして、NestJS は有力な候補かと思います。レイヤーやモジュール・DI の構
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 実装ファイルである」ことを指定するものです。
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
Next.js の API Routes から SWR の型推論を導く
ファイルシステム API Routes の課題 Next.js のファイルシステムを利用した routing は、直感的に定義を追加することができます。一方、モジュールシステム観点からは透過的参照がないため、TypeScript の型推論と相性が悪いです。Next.js における型安全な routing ソリューションとして pathpida がありますが、API Routes には対応していません。 useSWR から API Routes の API を呼ぶシーンで期待に沿うものが見当たらなかったので、今回自作してみました（リポジトリはこちら）本サンプルでは、npm script のpostinstallを hook に、src/types/pages/apiに生成ファイルが出力されるので、あらかじめnpm installを実行してお試しください。 サンプルで実現している型推論概要 は
Next.js 12 x React 18 について調べたメモ
'RSC'.reverse() == 'CSR' 現状公開されている情報から、Edge Functions を起点に Component を Streaming することが Vercel x Next.js x React 18 のゴールに見える。Edge Functions で RSC(React Server Components) を SSR するメリットは以下の様に考えている。 物理的に近い Edge サーバーなので速い V8 Isolete 実行環境のため立ち上がりの速い（Node 依存の Serverless より速い） CSR と比較しラウンドトリップが少ない このPR で Next.js に Server Components を導入した Shu Ding 氏がピン留めしている以下ツイートは必読。
Testing with Next.js
先日、Next.js におけるテスト手法について、公式ドキュメントが追加され話題になりました。 取り上げられている 2 者はよく知られており、いずれかに触れたことがある方も多いかと思います。この公式ドキュメントページでは「何を使って」を紹介しているのみなので、どちらを選ぶべきか悩んだ方もいるのではないでしょうか？ Cypress Jest & React Testing Library この判断についてはドキュメントに書かれていなかったので、筆者なりの見解を紹介していきたいと思います。 お勧めは「Jest & React Testing Library に寄せる」 Cypress は GUI が素晴らしく、テストを書く環境としてはとても体験が良いです。しかしテストが増えていくにつれ、以下のような点で DX 低下を招くことがあります。 CI の実行コストが高く、実行時間が長い cypress
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
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("更新しました");
React Component 分業の覚書
フロントエンドを Next.js 化する機会が多くなってきた昨今。いざ取り組むにしても、スタイリング込みで実装出来るエンジニアが不足気味ではないでしょうか？また、縦割り分業している現場ではこれまで、マークアップ（フロントエンド）エンジニアが html + css を納品し、それを元にサーバーサイドエンジニアがテンプレートエンジンに組み込むという業務フローも少なくありませんでした。 この様な業務フローの場合、同じリポジトリで作業してもらうという事が難しいこともあります。Next.js 移行期のこれからも同様のことが多々起きると予想しており、完全分業するうえでの最適化を考える必要があります。この件について少しまとめたくなったので、メモ書きとして残します。 前提条件 以下の座組みは React Component 分業で最適だと考えている組み合わせです。マークアップエンジニアはこれまでと変わらず
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 という難儀な仕組みを乗り越えるため、技術的に「そうせざるを得ない」理由が他にもあるのではないか。真
React.memo を濫用していませんか？ 更新頻度で見直す Provider 設計
React.memoを適用すれば、コンポーネントの不要な ReRender を防ぐことができます。しかしながら、Provider 設計・バケツリレーの見直しを行うことで、React.memoを使わずとも、ReRender の抑止は可能です。 最適な Context Provider 設計とすることで、React.memo使用によるオーバーヘッド削減が期待できます。そして「過剰な Provider 分割も場合によっては不要」ということを解説していきます。 3つのパターン サンプルリポジトリを用意しました。（Next.jsで作っていますが、特に意味はありません）「+1」押下でカウントアップし「input text」入力で、入力内容が更新される簡単なサンプルです。 こちらでは、以下３つのパターンが用意されています。ReRender されている様子は console.log 出力のほか、React
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Next.js の「next start・next dev」挙動差分一覧
Next.js と 非同期分割 CSS の悲劇