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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© LayerX Inc. 2 @izumin5210 whoami ▸ Wantedly, Inc. (2018-04 - 2022-08) ▸ LayerX (2022-09-) ‐ バクラク事業部 Platform Engineering 部 Enabling Team Staﬀ Software Engineer ▸ ISUCON14 4位 ▸ 好きなウェブサイトは https://astexplorer.net/

Slide 3

Slide 3 text

3 © LayerX Inc. 「すべての経済活動を、デジタル化する。」をミッションに、AI SaaSとAI DXの事業を展開事業紹介バクラク事業企業活動のインフラとなる業務を効率化するクラウドサービス Fintech事業ソフトウェアを駆使したアセットマネジメント‧証券事業を合弁会社にて展開 AI‧LLM事業社内のナレッジやノウハウをデータベース化するAIプラットフォーム AI SaaSドメイン AI DXドメイン

Slide 4

Slide 4 text

4 © LayerX Inc. 前提: バクラクについて LayerX Company Deck https://speakerdeck.com/layerx/company-deck?slide=22

Slide 5

Slide 5 text

5 © LayerX Inc. 前提: バクラクについて企業も候補者も納得する採⽤プロセスとは？〜LayerXの実践事例〜(2025-02-28) https://speakerdeck.com/layerx/winwin-engineer-hiring-layerx-202502?slide=23

Slide 6

Slide 6 text

複雑なフォームと複雑な状態管理にどう向き合うか

Slide 7

Slide 7 text

Slide 8

Slide 8 text

8 © LayerX Inc. 複雑なフォームと複雑な状態管理にどう向き合うかお客様の業務をデジタル化していくにあたって、使い勝⼿を左右する重要な接点（インタフェース）のひとつフォーム

Slide 9

Slide 9 text

TODO: 申請‧経費精算‧発⾏‧勤怠あたりの複雑そうなフォームのスクショ

Slide 10

Slide 10 text

10 © LayerX Inc. みなさんはどうやってフォームを実装していますか？（主に⼊⼒値のハンドリング‧データの取り回しの観点）

Slide 11

Slide 11 text

© LayerX Inc. 11 ▸ バクラクでは「フォームを作るための標準的な技術」として、 React Hook Form と Zod を推奨している - 頻出パターンを共通ライブラリにラップし、⽐較的少ない⼿間で「バクラクっぽいフォーム」が作れる仕組みを提供している ▸ React Hook Form がフォームにまつわる「めんどくささ」を吸収し、 Zod がモデリングとバリデーションを担う “フォーム” をどう作るか

Slide 12

Slide 12 text

Slide 13

Slide 13 text

13 © LayerX Inc. 便利！でもこれだけじゃたりない

Slide 14

Slide 14 text

14 © LayerX Inc. プロダクトが成⻑するとフォームも複雑になっていく

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

© LayerX Inc. 16 ▸ 例: 会⾷の経費精算 - 1⼈あたりの⾦額の上限がある - ⽇付‧⾦額‧出席者数を⼊⼒する - 申請時に単価が上限に引っかかっているかをチェックしたい - 単価は UI 上にも表⽰したい “フォーム” をどう作るか（ちょっとだけ複雑化した経費精算） ※ これくらいなら zod の reﬁne 等でも対応可能だが単価を UI 上にも表⽰したいなどの理由から独⽴したフィールドに

Slide 17

Slide 17 text

© LayerX Inc. 17 “フォーム” をどう作るか（ちょっとだけ複雑化した経費精算） React Hook Form は値の変更を監視することができるが… 同じような「別の値に連動して値が変化する」ケースがいっぱいあると⼤変なことになる（なった）「こういうロジックはサーバに寄せよう！」という話もあるが、それは体験とのトレードオフでもあるし、そもそもサーバに寄せても watch が必要になればしんどいことに変わりはない…

Slide 18

Slide 18 text

© LayerX Inc. 18 ▸ プロダクトの成⻑による機能の多様化により、 React Hook Form + Zod では複雑さを抱えきれなくなってくることも - 今回の例では、データの依存関係‧データの流れが追えなくなりつつあった - 先程の単価もほんの⼀例で、似たような‧より複雑なデータの流れが増えてくる - 「標準」はあったとしても、それが「万能」とは限らない - 銀の弾丸ではない… 的な ▸ 成⻑を続けるために、複雑さを受け⼊れられる設計に進化する必要がある React Hook Form や Zod は万能ではない

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© LayerX Inc. 22 ▸ 「何かの値を元に別の何かが決まる」を event driven にやってると⼤変 - 実質 goto (?) - じゃあ全ての更新処理を隠蔽してうまくやればいいのでは？ - と思うけど、React Hook Form だと任意のフィールドを setValue できるので完全な隠蔽は困難 ▸ “データの流れ”をモデリング‧実装でき、それを「強いる」ものがほしい - Redux, XState, class で気合でやる, ... いろいろ考えました - 今回は jotai を試すことに複雑なフォームの “データの流れ” をモデリングする

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© LayerX Inc. 28 ▸ React Hook Form が隠蔽していた「フォームのめんどくさいあれこれ」は⾃分で対処しないといけない - バリデーション発⽕タイミング, バリデーション結果つなぎこみ, パフォーマンスの⾼さ, etc. - フォームの「標準」とするには… どうでしょうね？ ▸ 結局は「⼀番重要な課題はなにか」を考えて技術選定する必要がある - 今回の例では「データの流れの整理」が⼀番重要な課題だった - この「データの流れ」がプロダクトの価値のコア部分なので、うまくモデリングしてあげることの重要性が⼤きい - プロダクトの性質によっては全然違う解になりうるもちろん、jotai も万能とはなりえない

Slide 29

Slide 29 text

Slide 30

Slide 30 text

© LayerX Inc. 30 ▸ これはテキストフィールドがあるような「フォーム」ではないが、「ユーザの操作によりデータが⼊⼒される」という意味では近い ▸ このプロダクトでは「データの流れ」よりも「ユーザが可能な操作とその結果」の複雑性が課題になっていた - なので jotai は悪くないが、ベストフィットという感じでもない - このときは巨⼤ Reducer による状態管理を選択した cf. 請求書レイアウトエディタ

Slide 31

Slide 31 text

© LayerX Inc. 31 ▸ いわゆる「銀の弾丸はない」というやつ ▸ 結局は「⼀番重要な課題はなにか」を考えて技術選定する必要がある - 経費精算の例では「データの流れの整理」が⼀番重要な課題だった - この「データの流れ」がプロダクトの価値のコア部分なので、うまくモデリングしてあげることの重要性が⼤きい - プロダクトの性質によっては全然違う解になりうる再掲: （フォームの）状態管理に標準はあれど万能はない

Slide 32

Slide 32 text

Slide 33

Slide 33 text

まとめ

Slide 34

Slide 34 text

34 © LayerX Inc. まとめ ▸ フォームの技術選定‧設計に標準はあれど万能は（たぶん）ない - もちろん、多くの（シンプルな）ケースで有⼒な選択肢というのはある - プロダクトの成⻑によって、元の設計では複雑さを受けきれなくなることもある ▸ データの流れ‧依存関係が複雑なケースでは、Jotai はうまく使えそう - 「データの流れ」をうまくモデリングし、そのままに近い形で実装に落とすことができる - 状態（State）である必要がないものを値（Derived Value）にすることで、複雑さを軽減することができそう ▸ そのプロダクト‧機能機能にとって「⼀番重要な課題はなにか」を考えて技術選定をするのが重要