Zodのデータ変換が便利すぎた。 しかし使いすぎで苦しくなっていった話

フロントエンドカンファレンス名古屋のLT登壇資料です。

Transcript

1. Zodのデータ変換が便利すぎた。 しかし使いすぎで苦しくなっていった話 パナソニック エレクトリックワークス株式会社 筧 万里 1 フロントエンドカンファレンス名古屋 2026 LT
2. 自己紹介 2 BANRI KAKEHI(@Melonps_) ◦ 家庭用燃料電池「エネファーム」のSRE ◦ クラウドネイティブ会議実行委員 ◦ Yamada UIのメンテナー エネファーム
3. スキーマ定義にどこまで書くか？ ◎Zodで型定義とバリデーションと両立させて使う形が多い 3 const UserSchema = z.object({ name: z.string(), age: z.number().min(0), email: z.email(), }); const result = UserSchema.safeParse({ name: "太郎", age: 1000, email: "taro@example.com", }); console.log(result.success, result.data) スキーマ定義(TS) パースによるランタイムでの検証 APIレスポンスの検証やフォーム入力制御で活躍
4. データ変換ツールとしても進化してきた .transform()：バリデーション後に型変換 4 const NameLengthSchema = z.string().transform((val) => val.length); type Input = z.input<typeof NameLengthSchema>; type Output = z.output<typeof NameLengthSchema>; .pipe()：変換後の値に再バリデーション const SafeStringToNumber = z.string() .transform((value) => Number(value)) .pipe(z.number().min(0).max(100)); numberが確定 0~100が確定
5. 何でこれが苦しくなるの？ 5 データ変換を使い倒して 便利だった実装と苦しくなっていった実装
6. 便利だった 便利だった実装：APIレスポンスの入り口 6 const EventSchema = z.object({ startAt: z.iso.datetime().transform((val) => new Date(val)), endAt: z.iso.datetime().transform((val) => new Date(val)), }).refine((data) => data.endAt.getTime() > data.startAt.getTime(), { message: "終了時刻は開始時刻より後に設定してください", path: ["endAt"], }); ◎APIから得たデータの論理と型の検証をする 論理の保証 ルールの整備がないままtransform化が進んでいった Date型へ変換
7. 苦しくなった const EventSchema = z.object({ startAt: z.iso.datetime().transform((val) => new Date(val)), endAt: z.iso.datetime().transform((val) => new Date(val)), attendees: z.array(z.object({ name: z.string(), role: z.string() })), }).transform((event) => ({ ...event, duration: event.endAt.getTime() - event.startAt.getTime(), activeAttendees: event.attendees.filter((a) => a.role !== "observer"), })); 苦しくなっていった実装 7 ◎データクレンジングや表示用の変換を持ち始めた →スキーマを追加するごとに、テストや議論が必要な状態に... 表示用の変換 useFormに渡す型はIn?Out？ フィルタリング
8. どうすれば良かったのか？ 8 ビジネスロジック ◎外部の不確実性から守るため、スキーマを境界の入り口とするべき ◦ 複数の境界をまたぐ変換は不適切 ◦ 同じ境界の中であれば、関数に切り出すべき Functional Core Mutable Shell
9. こう整理して挑戦中です 9 ◎スキーマを定義する前のチェックリスト リファクタ案やブランド型の話もしたかった... ◦ ①：「何と何の境界」を担っているか説明できるか？ ◦ ②：外→内への境界か、内→内への境界か？（後者なら関数に切り出す） ◦ ③：一つだけの境界を対象としているか？ ご清聴ありがとうございました！