はてなブックマーク

本稿は 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 いずれも公

この<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

AtomicDesign には「Atoms か Molecules か？、Molecules か Organisms か？」の判定が悩ましい…という課題があります。これは、フロントエンド・デザイナー間ではもちろん、デザイナー同士でも解釈差異があるようです。明確な判定軸がなければ、いずれブレが生じ、規律のないデザインシステムになりかねません。 この状況に対し「アクセシビリティを軸にする」という発想に至り、どのように仕分けるかを先日の投稿で紹介しました。このアイディアはタイトルのとおり「テスト」で機械的に判定可能です。 AtomicDesign カスタムマッチャー関数 「AtomicDesign の仕分けをテストで判定する」ために、独自のカスタムマッチャー関数を設けます。普段利用している'@testing-library/jest-dom'もカスタムマッチャーのライブラリですが、このカスタムマ

近日連投していた 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 高階関数

getServerSideProps や API Routes で未認証リクエストを弾く方法はいくつかあります。例えば、公式では HOF（Higher-Order Function）を使った例が紹介されていて（withSession関数）認証要件ページで利用できるアプローチです。今回は別のアプローチとして、関数合成を用いたものを紹介します。 関数合成とは 現在 stage2 の Pipe Operator でご存じの方も多いと思いますが、reduce を使って複数の関数を合成するテクニックがあります。合成された関数はシリアルに実行され、戻り値が次関数の引数となり、演算することができます。例えば以下の例では、0 から順番に 100,200,300 と加算していき、最終的に 600 を得ることができます。 function pipeSync(...fns) { return (args) =>

本稿は、Next.js で「getServerSideProps や API Routes」を利用するアプリケーション向け内容になります。重厚な作りになるので、要件に適合する・しないはあると思いますので、あしからず。 Next.js は薄いフレームワーク Next.js は SPA 配信の最適化にフォーカスしており、Backend の機能面が十分とは言えません。pages の Page コンポーネントや API Routes は、controller としての機能を提供するのみです。ドキュメントを見てもわかるとおり、一連処理はあらかじめ middleware やラッパー関数を用意するのが常套手段かと思います。 NestJS にあるような Service 層が欲しい Node.js Backend フレームワークとして、NestJS は有力な候補かと思います。レイヤーやモジュール・DI の構

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

Next.js は、ページ単位でデータ取得・レンダリング手法を選べる事が利点です。そして、ページ単位でチャンクファイルが生成されるため、パフォーマンスに貢献します。 これはあるページに来訪した際、必要最低限のファイルロードで済むということです。ファイルロードの時間は、ユーザーが操作開始できるまでの時間（TTI）に繋がります。Next.js でコーディングしていれば意識せずとも、ファイル分割の最適化は適用されます。 これだけでも SPA 構築に Next.js を選ぶ理由になりますが、ファイル分割は実装次第で、良くも悪くもなることを紹介していきます。 First Load JS shared by all _appは、どのページにアクセス・ナビゲーションしても、必ず通過します。そのため、_appに関連するファイルは 「First Load JS shared by all」 として、全てのペ

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

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 を生成する必要があります。前者は面倒なので、

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 実装ファイルである」ことを指定するものです。

try { const data = await fetchSomething(); // 正常系レスポンスの処理 } catch (err) { if (isAxiosError(err)) { // 異常系レスポンスの処理 } } 動機はつぎの 3 つです。 データ取得も宣言的に書きたいから データ取得に関係ない例外も catch してしまうから HttpError の集計に不便だから データ取得も宣言的に書きたいから 要約すると、データ取得時は常にこのように書きたい、という話です。useSWR・useQuery や apollo/client でお馴染みのインターフェイスです。 const { data, err, status } = await fetchSomething(); if (data) // 正常系レスポンスの処理 if (err) // 異常系レスポンスの処理

NestJS で Prisma を扱うとき、発行されるクエリがどんなものか追いたかったのですが、いずれの公式ドキュメントにも明記されていなかったため備忘録です。 なお、執筆環境の依存モジュールバージョンは以下の通りです。バージョン差異による不具合はご了承ください。 "dependencies": { "@nestjs/common": "^8.0.0", "@nestjs/core": "^8.0.0", "@prisma/client": "^3.11.1", "prisma": "^3.11.1" } Prisma on NestJS の雛形 NestJS で Prisma を利用する場合、インスタンス化せず以下の様に service として定義、各々の module で利用します。DB 接続を試行するライフサイクルイベントonModuleInitの定義は現在オプションですが、後続解説

MSW のハンドラー型推論 テストや Storybook で利用事例が増えている MSW。GraphQL の場合、@graphql-codegen/typescript-mswというプラグインを使えば、良い感じの MSW ハンドラーを生成してくれます。これがあれば、MSW ハンドラー関数起因のミス削減が期待できます。 import { mockGetUserQuery } from "./generated"; const worker = setupWorker( mockGetUserQuery((req, res, ctx) => { // id の型推論が効いている const { id } = req.variables; return res( ctx.data({ // 型制約が効いており、スキーマに沿ったレスポンスしか返せない getUser: { name: "John

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=