複雑なフォームを継続的に開発していくための技術選定・設計・実装 #tskaigi / #tskaigi2025

by Masayuki Izumi

Slide 1

Slide 1 text

複雑なフォームを継続的に開発していくための技術選定・設計・実装 2025-05-24 TSKaigi 2025 @izumin5210

Slide 2

Slide 2 text

@izumin5210 © LayerX Inc. whoami LayerX バクラク事業部 (2022-09 -) Platform Engineering 部 Enabling チーム Staff Software Engineer ISUCON14 4位好きな関数は cva

Slide 3

Slide 3 text

「フォーム」って難しくないですか？単純だったらいいけど、フィールド数が多かったり、画面が多かったり、補完やフィールドのバリエーションが多かったり… © LayerX Inc. 3

Slide 4

Slide 4 text

たとえば経費精算フォーム。裏側のビジネスルールの複雑さ・ペインを利用者からなるべく隠蔽する代わりに、実装でやることは多い。さらに、事業会社の自社プロダクトは進化し続ける必要があるが、その一方でバグ・デグレを最小限に抑える必要もある © LayerX Inc. 4

Slide 5

Slide 5 text

難しい（複雑な, 大規模な, 成長する, etc.）フォームに、設計と技術選定で立ち向かう話をします © LayerX Inc. 5

Slide 6

Slide 6 text

Slide 7

Slide 7 text

最も単純な実装 © LayerX Inc. useState だけこの時点で将来的に困る気配がするフィールドが増えると useState も増える 1フィールド更新しただけで全体再描画バリデーションどうする？これ以上複雑にならないなら全然これでもいい 7

Slide 8

Slide 8 text

フォームライブラリで便利にコード例は React Hook Form © LayerX Inc. 基礎的な面倒事は吸収してくれる useForm してを register するいいかんじに再描画を減らすバリデーションの実行と制御もやってくれるフィールドが多少増えた程度なら、これだけでも戦える ...本当に？ 8

Slide 9

Slide 9 text

フォームライブラリで便利に？見た目の話と振る舞いの話が混ざるのは（特に規模が大きいと）厳しい © LayerX Inc. フィールドが多少増えた程度なら、これだけでも戦える ...本当に？ UI に埋もれるバリデーション記述見通しづらい, 対応漏れやすい, テストしづらい, ... バリデーションも重要なロジック 9

Slide 10

Slide 10 text

フォームライブラリ + バリデーションスキーマコード例は React Hook Form + Zod © LayerX Inc. フォームが扱う値の構造と制約を宣言的に記述できる（させる) 重要なロジックや構造を UI から独立して扱えるバリデーションのついでにフォームのモデリングを開発者に促す 10

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

ここからフォームの例を複雑にしていきどうモデルを進化させるかみていきます © LayerX Inc. 14

Slide 15

Slide 15 text

もうちょっと大変にしてみる © LayerX Inc. EC サイトのカートを考える商品と数量から合計金額が決まる合計金額も画面に表示する 15

Slide 16

Slide 16 text

もうちょっと大変にしてみる © LayerX Inc. EC サイトのカートを考える商品と数量から合計金額が決まる合計金額も画面に表示する合計金額に制限がある ← New! 16

Slide 17

Slide 17 text

もうちょっと大変にしてみる © LayerX Inc. EC サイトのカートを考える商品と数量から合計金額が決まる合計金額も画面に表示する合計金額に制限がある小計も ← New! 17

Slide 18

Slide 18 text

フォームライブラリ + バリデーションスキーマの限界 © LayerX Inc. React Hook Form + Zod でいうと、 watch や setValue が増えだしたらアラート多少ならまだいいが、 useEffect とかと組み合わさり始めるとかなり危険信号危険なサインの例 useEffect or watch で setValue を手続き的に呼び出すことによるバグ混入リスクイベントハンドラ内であっても、フォーム状態を無秩序に setValue することによる、重要な書き込みロジックが無視されるリスクモデルの振る舞いをコードに反映できてないサインかも 18

Slide 19

Slide 19 text

フォームライブラリ + バリデーションスキーマの限界 © LayerX Inc. 参考: useEffect + setState は危険信号そのエフェクトは不要かも – React https://ja.react.dev/learn/you-might-not-need-an-effect 詳解：フロントエンドの状態とリアクティブ (なぜuseEffect()でsetState()がアンチパターンか) https://zenn.dev/layerx/articles/22dd45dc69a57c 19

Slide 20

Slide 20 text

フォームライブラリ + バリデーションスキーマの限界 © LayerX Inc. Zod でモデリングできるのはあくまで「形状」と「制約」だけそれ以上の、たとえば今回のような計算・ロジックは組み込みづらい（頑張ればできるが、Zod の宣言的に書ける良さは活きづらい） 20

Slide 21

Slide 21 text

適切なモデルを考える © LayerX Inc. 今回の例（小計・合計）は、「ある値から別の値を計算し、表示やバリデーションに使いたい」というもの RHF + Zod の都合に合わせるために、計算結果を状態に書く単純なプログラムなら「一度状態に持つ」ということはしないのでは？状態にせず値としたい 21

Slide 22

Slide 22 text

適切なモデルを支える技術選定例 © LayerX Inc. オブジェクト指向のようなモデルがフィットしているなら、MobX が選択肢に上がるかもデータの依存を素直に記述でき、それを効率よく React に伝えてくれる実行時にデータの依存（今回だと getter が何を読んだか）を追跡し、更新検知・再描画をしてくれるとはいえ MobX は癖があるし、OOP が React を触るエンジニアにとって扱いやすいかなど、別角度での検討事項は多い 22

Slide 23

Slide 23 text

コードはぱっと見でわかりやすくなった？自分が OOP に慣れてるからかもしれない React Hook Form とは独立したコードになっているのも、関心の分離・テスト観点で嬉しい © LayerX Inc. 23

Slide 24

Slide 24 text

ポイント① モデルは「形状」だけでなく、ロジック・振る舞いも含める © LayerX Inc. Zod だと「形状」「制約」にとどまることが多いが、実際のプロダクトの複雑なフォームでは、そこ以外にも重要な概念がある「合計金額は数量と金額の掛け算」とかはシンプルだが、現実はもっと難しいはずそういうドメイン上重要なものに名前をつけて、重要だとわかるようにしたい 24

Slide 25

Slide 25 text

ポイント② フォームにおけるモデルを UI から分離する © LayerX Inc. React Hook Form + Zod だと厳しくなってくるようなフォームでは、価値の高い・重要なロジックが埋まっていることも多いはずそれらを UI から分離し「（重要な）モデルである」というのをわかりやすく・見通しやすく・テストしやすくしておきたいそこをより重点的にテストする, そこはより注意してレビューする, ... 開発者の認知や行動を切り替える（とはいえ規模や複雑さがそうでもないなら UI に co-locate させるほうがメンテしやすい。要はバランス。） AI 向けにもモデルと UI が分離されたほうが動きやすいし、我々ももレビューしやすい…んじゃないかな？ 25

Slide 26

Slide 26 text

ポイント③ なるべく状態ではなく、値として扱う © LayerX Inc. 状態は難しい内部の状態の存在を知っていないと、その外から見た振る舞いを正しく知ることは難しい状態への書き込みを「適切に（もれなく・ミスなく）」徹底する難易度は高い今回の例のように readonly な「別の値から計算される値（Derived Value）」として扱うことができれば、扱いは非常に単純 26

Slide 27

Slide 27 text

MobX が常に絶対最強？もちろんそんなことはない © LayerX Inc. 27

Slide 28

Slide 28 text

もうちょっと大変にしてみる © LayerX Inc. EC サイトのカートを考える商品と数量から合計金額が決まる合計金額も画面に表示する合計金額に制限があるドル決済のときはレートを API から取得する ← New! 28

Slide 29

Slide 29 text

値に非同期処理が絡むなど、依存がさらに複雑なケース © LayerX Inc. MobX でも解くことはできるが、MobX は依存追跡をランタイムで実現しているため複雑すぎる依存ではデバッグがつらかったりするこの発表では詳しくは触れません。技術にはいろんな特性があるんだなあくらいで捉えておいてもらえると。ほかの技術だと、たとえば jotai などは複雑な依存や非同期の依存でもうまく扱える 29

Slide 30

Slide 30 text

jotai の簡単な例 © LayerX Inc. jotai は atom という単位で状態を管理する atom 関数は読み書き可能な状態のほか、 Read only な atom をつくることで、他の値に依存した値（Derived Value）を表現可能この get(anAtom) の形でデータの依存グラフを描く 30

Slide 31

Slide 31 text

jotai で非同期の Derived Value を扱う例 © LayerX Inc. Read only atom は非同期の値を返すこともできる非同期 atom もだいたい通常の atom と同じように扱える解説サボるために実装を簡略化しています。実際の利用方法は以下の記事を参照してください「Jotai v2を使いこなすために実は必須級な“async sometimes”パターンの解説」 by uhyo https://zenn.dev/uhyo/articles/jotai-v2-async-sometimes 31

Slide 32

Slide 32 text

jotai は atom でデータの依存グラフを描く青が状態, オレンジが Derived Value get(anAtom) がグラフのエッジ © LayerX Inc. 32

Slide 33

Slide 33 text

jotai によるモデリング © LayerX Inc. MobX のときに挙げたポイントは jotai もクリアしているポイント① モデルは「形状」だけでなく、ロジック・振る舞いも含めるポイント② フォームにおけるモデルを UI から分離するポイント③ なるべく状態ではなく、値として扱うやはり「ロジックを」「UI と分離して」「値でいいものは値として扱う」ことで余計な複雑性を抑えたモデリングができる 33

Slide 34

Slide 34 text

jotai によるモデリング - 非同期処理 © LayerX Inc. 非同期処理を含む atom への依存をそこまで特別扱いせず、おなじく atom の形で書けるのが強力前述のレートの例のような「ユーザの入力値を API に渡し、そのレスポンスを別の値やバリデーションに利用」は稀によくあるケース非同期処理のために処理の流れを捻じ曲げたり、余計な中間状態を生やしたりは不要。いつもの async function で OK。 React にマウントするときにまだ未解決なら勝手に Suspend してくれる便利！ …だけど、同じ useAtomValue が atom によって suspend したりしなかったりするのは逆に認知負荷たかいかも…？ともちょっと思う。むずかしい。 34

Slide 35

Slide 35 text

Slide 36

Slide 36 text

「フォームのモデリング」という観点から見ると解いてる課題は近いデータの依存を Derived Value として表現することで無理のないコードとなり、余計な複雑性を下げることにつながっているここでいう無理のあるコードとは、状態の更新にフックして別の状態の更新を頑張っていたコード MobX （一見して）普通のクラスで書ける / 暗黙で依存追跡する / ... jotai 独自記法・概念がある / `get(anAtom)` の形で依存を明示する / ... © LayerX Inc. 36

Slide 37

Slide 37 text

MobX と jotai - どっちにするか © LayerX Inc. 依存追跡の方法が大きく違う MobX はランタイムで暗黙的に呼び出しを記憶 jotai は get(anAtom) の呼び出しをリアクティブな（更新されうる）値の呼び出しとする get(anAtom) の記述など、独自 DSL 感のある jotai か普通の OOP / クラスっぽくかける代わりに、良くも悪くも暗黙的な挙動が多い MobX か 37

Slide 38

Slide 38 text

Slide 39

Slide 39 text

問題によって適するモデル・設計は変わるモデル・設計が変われば適する技術も変わる © LayerX Inc. 今回は偶然 Derived Value / データの依存グラフ / データの流れなどに着目した設計がハマる問題（プロダクト特性）だった問題（プロダクトや機能）によって適する回答は変わりうるウィザードっぽい複数画面からなるフォームであれば、 XState のような状態遷移に着目した技術が適するかも Undo 機能みたいなものが必要なら Redux / Zustand などが適するかも単にフィールドが多いだけのフォームなら、 Zod で「形状」をモデリングするだけで事足りるかもプロダクトの複雑さはどこから来ているかを見極める 39

Slide 40

Slide 40 text

「フォーム」にこだわりすぎない © LayerX Inc. 今回の例も、フォームの問題にフォーム専用でない状態管理ライブラリを持ち込んでいる表面的な要素に囚われすぎず、「いまどんな問題に向き合ってるんだろう」を一段上から考えてみる e.g. 「相関バリデーションが難しいことに困ってたんだけど、実はデータの依存関係をうまくモデリングできていないだけだな」 40

Slide 41

Slide 41 text

フォームライブラリを使わないことで失うものもある © LayerX Inc. これもトレードオフのひとつたとえば React Hook Form であれば、各フィールドの dirty check, バリデーション発火タイミング制御, etc. なくなったら面倒ではあるが、「本質的な複雑さ」というよりは「シンプルに面倒」な類のものも多いなので最小限のユーティリティを実装してなんとかするという手もある 41

Slide 42

Slide 42 text

複数の技術・設計を組み合わせるパターンもありうる © LayerX Inc. たとえば以下の2つは両立しうる「バリデーション対象フィールドが多いので Zod で宣言的に記述したい」「依存関係を持つフィールドが多いので jotai を使いたい」 Zod のバリデーション結果も Derived Value にしてしまえばいい jotai と Zod を組み合わせると、 superRefine などは不要になるはず 42

Slide 43

Slide 43 text

最初から100点の答えを見つけに行く必要はない © LayerX Inc. 特に PMF 前のプロダクトや機能のプロトタイプフェーズなどでは、あるべきの形が見えてないことも多いそんな状態で未来を先読みするのは難しいし打率も低いなので、そこそこいい感じになるところから始めようやはりフォームライブラリ（e.g. React Hook Form）とバリデーションスキーマ（e.g. Zod）の組み合わせから入るのはコスパがいいまあこの2つで事足りるケースのほうが多いだろうし… 43

Slide 44

Slide 44 text

Slide 45

Slide 45 text

「変更影響を受けた（壊れた）こと」に早く気付けるコードを書く © LayerX Inc. 気づくスピード: 型 > Lint > Unit Test > ... > エンドユーザ特に規模が大きい/複雑/パターン数が多い部品ではなるべく型やテストが最初に壊れるようにしておく現状の仕様をモデル+テストで表現できているのであれば型で将来的な拡張への耐性を上げることが有効 45

Slide 46

Slide 46 text

早く壊れる型の例. などなど… © LayerX Inc. enum, union で取りうる値の幅が増えてハンドル漏れが起きるケース foo satisfies never のような Exhaustiveness checking を常に書く渡せるパラメタが増えたが、呼び出し側でその対応が漏れるケースアプリケーションコードでは optional は使わない（不要なら null などを明示的に渡させる）変更が伝播し、意図せず Atom の型（関数の返り値）が変わって壊れる関数の返り値型は推論に頼らず明示する 46

Slide 47

Slide 47 text

限界を迎えるサインには気をつける © LayerX Inc. 設計が限界を迎える（プロダクトの複雑さを受け入れきれなくなる）と、機能開発に時間かかったりバグが増えたりするどれだけ丁寧に進めても、プロダクトの進化を読みきれず設計が耐えきれなくなることはありうるさっきの話と同じで、完璧な先読みはできない限界を迎える兆候にはやめに気づいて手を打ち始められると Good React Hook Form でいうと、 watch や setValue が増えだしたらアラート 47

Slide 48

Slide 48 text

おわり © LayerX Inc. フォームは難しい「ユーザに変更される状態を持つ UI」の難しさと、「プロダクト由来の難しさ」の両方に直面する問題領域に適したモデリング・適した技術選定をすることで、後者の複雑さメンテナンス性は改善できるはずたとえばデータの依存が複雑なのであれば、Derived Value をうまく扱える MobX や jotai は有効最初から最適な選択は困難なので、限界を迎えるサインに早めに気付けるようにしたい 48