複雑なフォームと複雑な状態管理にどう向き合うか / #newt_techtalk vol. 15

【LayerX/ベースマキナ/令和トラベル】サービスの成長に合わせたフロントエンドの進化 - connpass https://reiwatravel.connpass.com/event/346339/

Transcript

1. © LayerX Inc. 複雑なフォームと複雑な状態管理にどう向き合うか 2025-03-18 NEWT Tech Talk vol.15 サービスの成⻑に合わせたフロントエンドの進化 #newt_techtalk @izumin5210
2. © LayerX Inc. 2 @izumin5210 whoami ▸ Wantedly, Inc. (2018-04 - 2022-08) ▸ LayerX (2022-09-) ‐ バクラク事業部 Platform Engineering 部 Enabling Team Staff Software Engineer ▸ ISUCON14 4位 ▸ 好きなウェブサイトは https://astexplorer.net/
3. 3 © LayerX Inc. 「すべての経済活動を、デジタル化する。」をミッションに、AI SaaSとAI DXの事業を展開 事業紹介 バクラク事業 企業活動のインフラとなる業務を 効率化するクラウドサービス Fintech事業 ソフトウェアを駆使したアセットマネジ メント‧証券事業を合弁会社にて展開 AI‧LLM事業 社内のナレッジやノウハウをデータ ベース化するAIプラットフォーム AI SaaSドメイン AI DXドメイン
4. 4 © LayerX Inc. 前提: バクラクについて LayerX Company Deck https://speakerdeck.com/layerx/company-deck?slide=22
5. 5 © LayerX Inc. 前提: バクラクについて 企業も候補者も納得する採⽤プロセスとは？ 〜LayerXの実践事例〜(2025-02-28) https://speakerdeck.com/layerx/winwin-engineer-hiring-layerx-202502?slide=23
6. 複雑なフォームと複雑な状態管理に どう向き合うか
7. © LayerX Inc. 7 ▸ “フォーム”をどう作るか ‐ 標準的なフォームでどうするか ‐ 複雑になってきたフォームは？ ▸ 複雑なフォーム（の状態）にどう向き合うか ‐ データの流れが複雑なフォームで jotai を使う例 ▸ 複雑な（フォームの）状態にどう向き合うか 今⽇話すこと 今⽇話すこと
8. 8 © LayerX Inc. 複雑なフォームと複雑な状態管理にどう向き合うか お客様の業務をデジタル化していくにあたって、 使い勝⼿を左右する重要な接点（インタフェース）のひとつ フォーム
9. TODO: 申請‧経費精算‧発⾏‧勤怠あたりの 複雑そうなフォームのスクショ
10. 10 © LayerX Inc. みなさんはどうやってフォームを実装していますか？ （主に⼊⼒値のハンドリング‧データの取り回しの観点）
11. © LayerX Inc. 11 ▸ バクラクでは「フォームを作るための標準的な技術」として、 React Hook Form と Zod を推奨している - 頻出パターンを共通ライブラリにラップし、 ⽐較的少ない⼿間で「バクラクっぽいフォーム」が作れる仕組みを提供している ▸ React Hook Form がフォームにまつわる「めんどくささ」を吸収し、 Zod がモデリングとバリデーションを担う “フォーム” をどう作るか
12. © LayerX Inc. 12 “フォーム” をどう作るか（経費精算を例に） ⽐較的簡単に、パフォーマンスの良いフォームが作れる 宣⾔的で、⾒通しの良いバリデーション ついでにフォームのモデリングができるのも素敵
13. 13 © LayerX Inc. 便利！ でもこれだけじゃたりない
14. 14 © LayerX Inc. プロダクトが成⻑すると フォームも複雑になっていく
16. © LayerX Inc. 16 ▸ 例: 会⾷の経費精算 - 1⼈あたりの⾦額の上限がある - ⽇付‧⾦額‧出席者数を⼊⼒する - 申請時に単価が上限に引っかかっているかを チェックしたい - 単価は UI 上にも表⽰したい “フォーム” をどう作るか（ちょっとだけ複雑化した経費精算） ※ これくらいなら zod の refine 等でも対応可能だが 単価を UI 上にも表⽰したいなどの理由から独⽴したフィールドに
17. © LayerX Inc. 17 “フォーム” をどう作るか（ちょっとだけ複雑化した経費精算） React Hook Form は値の変更を監視することができるが… 同じような「別の値に連動して値が変化する」ケースがいっぱいあると⼤変なことになる（なった） 「こういうロジックはサーバに寄せよう！」という話もあるが、それは体験とのトレードオフでもあるし、 そもそもサーバに寄せても watch が必要になればしんどいことに変わりはない…
18. © LayerX Inc. 18 ▸ プロダクトの成⻑による機能の多様化により、 React Hook Form + Zod では複雑さを抱えきれなくなってくることも - 今回の例では、データの依存関係‧データの流れが追えなくなりつつあった - 先程の単価もほんの⼀例で、似たような‧より複雑なデータの流れが増えてくる - 「標準」はあったとしても、それが「万能」とは限らない - 銀の弾丸ではない… 的な ▸ 成⻑を続けるために、複雑さを受け⼊れられる設計に進化する必要がある React Hook Form や Zod は万能ではない
19. © LayerX Inc. 19 ▸ 解くべき課題がデータの依存関係‧データの流れに移っていた - React Hook Form や Zod はいいライブラリであり、 フォームに関する課題の多くを解決してくれることには変わりない - だが、いま直⾯している「最も⼤きな課題」に対する有⼒な解決策は持っていない 解くべき課題は？
20. © LayerX Inc. 20 複雑になったデータの流れ‧依存関係
21. © LayerX Inc. 21 複雑になったデータの流れ‧依存関係 現実のプロダクトは、⾦額まわりだけを⾒てもかなり複雑なデータの流れになる （これでもだいぶ簡略化してる）
22. © LayerX Inc. 22 ▸ 「何かの値を元に別の何かが決まる」を event driven にやってると⼤変 - 実質 goto (?) - じゃあ全ての更新処理を隠蔽してうまくやればいいのでは？ - と思うけど、React Hook Form だと任意のフィールドを setValue できるので 完全な隠蔽は困難 ▸ “データの流れ”をモデリング‧実装でき、それを「強いる」ものがほしい - Redux, XState, class で気合でやる, ... いろいろ考えました - 今回は jotai を試すことに 複雑なフォームの “データの流れ” をモデリングする
23. © LayerX Inc. 23 jotai によるデータの流れのモデリング
24. © LayerX Inc. 24 jotai によるデータの流れのモデリング 状態の依存グラフがコード上に表現できる Read-only derived atom により、「他の値から計算して決まる値（Derived Value）」を 安全に‧他の値と同じように扱うことができる 状態（State）を減らし、値（Derived Value）に寄せることで管理するものを減らす
25. © LayerX Inc. 25 jotai によるデータの流れのモデリング バリデーションエラーも Derived Value と捉えることで、グラフ上に表現できる
26. © LayerX Inc. 26 jotai によるデータの流れのモデリング データの依存グラフ上にロジックも実装することになるので、 UI ⾮依存のユニットテストで多くをシンプルにテストできる （jotai のコアは React など UI ライブラリに⾮依存になっている！ 悪事の妄想が捗りますね！）
27. © LayerX Inc. 27 jotai によるデータの流れのモデリング Read-only derived atom も通常の atom と同じように React につなぎこむことが可能
28. © LayerX Inc. 28 ▸ React Hook Form が隠蔽していた「フォームのめんどくさいあれこれ」は ⾃分で対処しないといけない - バリデーション発⽕タイミング, バリデーション結果つなぎこみ, パフォーマンスの⾼さ, etc. - フォームの「標準」とするには… どうでしょうね？ ▸ 結局は「⼀番重要な課題はなにか」を考えて技術選定する必要がある - 今回の例では「データの流れの整理」が⼀番重要な課題だった - この「データの流れ」がプロダクトの価値のコア部分なので、 うまくモデリングしてあげることの重要性が⼤きい - プロダクトの性質によっては全然違う解になりうる もちろん、jotai も万能とはなりえない
29. © LayerX Inc. 29 cf. 請求書レイアウトエディタ
30. © LayerX Inc. 30 ▸ これはテキストフィールドがあるような「フォーム」ではないが、 「ユーザの操作によりデータが⼊⼒される」という意味では近い ▸ このプロダクトでは「データの流れ」よりも 「ユーザが可能な操作とその結果」の複雑性が課題になっていた - なので jotai は悪くないが、ベストフィットという感じでもない - このときは巨⼤ Reducer による状態管理を選択した cf. 請求書レイアウトエディタ
31. © LayerX Inc. 31 ▸ いわゆる「銀の弾丸はない」というやつ ▸ 結局は「⼀番重要な課題はなにか」を考えて技術選定する必要がある - 経費精算の例では「データの流れの整理」が⼀番重要な課題だった - この「データの流れ」がプロダクトの価値のコア部分なので、 うまくモデリングしてあげることの重要性が⼤きい - プロダクトの性質によっては全然違う解になりうる 再掲: （フォームの）状態管理に標準はあれど万能はない
32. © LayerX Inc. 32 関連: https://zenn.dev/layerx/articles/22dd45dc69a57c
33. まとめ
34. 34 © LayerX Inc. まとめ ▸ フォームの技術選定‧設計に標準はあれど万能は（たぶん）ない - もちろん、多くの（シンプルな）ケースで有⼒な選択肢というのはある - プロダクトの成⻑によって、元の設計では複雑さを受けきれなくなることもある ▸ データの流れ‧依存関係が複雑なケースでは、Jotai はうまく使えそう - 「データの流れ」をうまくモデリングし、そのままに近い形で実装に落とすことができる - 状態（State） である必要がないものを値（Derived Value）にすることで、 複雑さを軽減することができそう ▸ そのプロダクト‧機能機能にとって 「⼀番重要な課題はなにか」を考えて技術選定をするのが重要
35. 35 © LayerX Inc. 宣伝 宣伝: 弊社でも Web Frontend のイベントをします！ テーマは “Exploring State”！