はじめに
React、Next.js、TypeScriptを触れる中で、自身がより品質管理の面を強化したいと思い、導入するところから自己学習で勉強しました。
使用した主な技術は以下です。
- React
- Next.js
- TypeScript
- フォームのライブラリ: React Hook Form
- バリデーション: Zod
- UIカタログ: Storybook
- テスト: React Testing Library + Jest
- スタイリング: Tailwind CSS
なぜこの構成にしたのか？
フォーム開発では、「正しくバリデーションされるか」「エラー表示が適切か」など、細かな品質担保が重要になります。
特に今回の目標は、
- バリデーションロジックを型安全に管理したい
- UIの見た目とエラーパターンを整理しておきたい
- テストでフォームの振る舞いを保証したい
という理由から、この技術スタックを採用しました。
各ツールの役割と実装ポイント
React Hook Form
- 軽量で、フォーム管理の負担が少ない。
- バリデーションもresolverを使うだけで外部ライブラリと簡単に連携できる。
const { register, handleSubmit, formState: { errors } } = useForm<RegisterFormInputs>({
resolver: zodResolver(registerSchema),
});
Zod
- TypeScriptとの親和性が非常に高い。
- スキーマと型を一元管理できるので、バリデーションルールの漏れを防止できる。
export const registerSchema = z
.object({
name: z.string().min(2, "名前は2文字以上で入力してください"),
email: z.string().email("有効なメールアドレスを入力してください"),
password: z.string().min(6, "6文字以上で入力してください"),
confirmPassword: z.string(),
})
.refine((data) => data.password === data.confirmPassword, {
message: "パスワードが一致しません",
path: ["confirmPassword"],
});
export type RegisterFormInputs = z.infer<typeof registerSchema>;
Storybook
- コンポーネント単位でUI・エラー表示パターンを確認できる。
- 異常系（エラー表示時）も簡単に切り替えて確認できるので、デザイナーや他メンバーとのレビューがスムーズになった。
Testing Library
- ユーザー視点で、フォーム操作〜エラー表示までの挙動をテストできる。
import { render, screen, fireEvent, waitFor } from "@testing-library/react";
import { RegisterForm } from "@/app/components/RegisterForm";
import * as api from "@/app/lib/api";
jest.mock("@/app/lib/api", () => ({
sendRegisterRequest: jest.fn(),
}));
describe("RegisterForm", () => {
it("renders all input fields", () => {
render(<RegisterForm />);
expect(screen.getByLabelText("名前")).toBeInTheDocument();
expect(screen.getByLabelText("メールアドレス")).toBeInTheDocument();
expect(screen.getByLabelText("パスワード")).toBeInTheDocument();
expect(screen.getByLabelText("パスワード確認")).toBeInTheDocument();
});
it("shows validation errors on submit without input", async () => {
render(<RegisterForm />);
fireEvent.click(screen.getByText("登録"));
await waitFor(() => {
expect(
screen.getByText("名前は2文字以上で入力してください")
).toBeInTheDocument();
expect(
screen.getByText("有効なメールアドレスを入力してください")
).toBeInTheDocument();
expect(
screen.getByText("6文字以上で入力してください")
).toBeInTheDocument();
});
});
it("submits form when valid data is entered", async () => {
const mockSendRegister = jest.spyOn(api, "sendRegisterRequest");
// .mockResolvedValue({ success: true });
render(<RegisterForm />);
fireEvent.input(screen.getByLabelText("名前"), {
target: { value: "太郎" },
});
fireEvent.input(screen.getByLabelText("メールアドレス"), {
target: { value: "taro@example.com" },
});
fireEvent.input(screen.getByLabelText("パスワード"), {
target: { value: "password123" },
});
fireEvent.input(screen.getByLabelText("パスワード確認"), {
target: { value: "password123" },
});
fireEvent.click(screen.getByText("登録"));
await waitFor(() => {
expect(mockSendRegister).toHaveBeenCalledWith({
name: "太郎",
email: "taro@example.com",
password: "password123",
confirmPassword: "password123",
});
});
});
});
工夫したこと
READMEに設計方針やディレクトリ構成を明記
-
ディレクトリ構成（例：src/components/, src/lib/, src/schemas/ など）
-
技術選定理由（React Hook Form / Zod を選んだ背景）
-
各コンポーネントの責務と依存関係
-
データフローやバリデーションの設計方針
コンポーネントを分割し、責務を明確にする
フォームに必要なUIパーツ（例：TextInput, FormError）を共通コンポーネントとして分割しました。
type TextInputProps = {
label?: string;
name: string;
} & React.InputHTMLAttributes<HTMLInputElement>;
export const TextInput = ({ label, name, ...props }: TextInputProps) => (
<div>
{label && (
<label htmlFor={name} className="text-sm font-semibold">
{label}
</label>
)}
<input id={name} name={name} {...props} className="border p-2" />
</div>
);
-
TextInputは純粋にUIだけを担当
-
エラー表示はFormErrorに分離
-
バリデーションロジックはzodとregisterSchemaに集約
このように責務ごとにコンポーネントを分割することで、StorybookでのUI確認や単体テストがしやすくなり、保守性・再利用性が大幅に向上しました。
おわりに
ここまで読んでいただきありがとうございました！
今後はUIコンポーネントを作る際も、見た目だけでなく「なぜこう設計するのか？」を意識しながら、より良いアーキテクチャと設計判断ができるフロントエンドエンジニアを目指していきたいと思います。