複雑性の高いオブジェクト編集に向き合う: プラガブルなReactフォーム設計

2024/12/12 ～Tech-Front Meetup～ 一歩先のフロントエンドへ 登壇資料
https://levtechcareer.connpass.com/event/337755/

Transcript

1. 複雑性の高いオブジェクト編集に向き合う 
 プラガブルな Reactフォーム設計 
 
 @2024/12/12 ～Tech-Front Meetup～ 一歩先のフロントエンドへ 
 1
2. © 2024 RightTouch Inc. アジェンダ 
 2 自己紹介・会社紹介 
 
 
 発表の目的と背景 
 
 
 フォーム実装の実際 

3. © 2024 RightTouch Inc. 3 自己紹介
 2020 東京大学理学系研究科博士課程修了 
 
 2020-2021 日立製作所
 
 2021-2024 株式会社プレイド
 
 2021-現在 株式会社RightTouch
 
 
 レーザー物理で博士号取得後、日立製作所で ITプラットフォームの設 計・開発に従事。
 
 その後、プレイド/RightTouchで、テックリード/フルスタックエンジニア としてアプリケーション開発に従事。 
 
 
 好きなもの: 旬
 
 
 齋藤 成之
 X: @nakaakist

4. © 2024 RightTouch Inc. 会社紹介
 沿革 
 2021年12月 株式会社RightTouch設立
 2022年3月 次世代のコンタクトセンターを創ることに賛同いただいた 
 お客様との実証実験を経て、 KARTE RightSupport（β版）
 をリリース 2023年10月 Webサイトとコールセンターの分断をなくし、問い合わせ体験を抜 本から変革する新プロダクト「 RightConnect by KARTE」β版を 提供開始
 2023年10月 RightSupport by KARTEの正式版をリリース 
 
 主な導入企業様 設立：2021年12月
 従業員：40名、うちエンジニア15名（2024年8月1日現在）
 資本金：10,000,000円（資本準備金含む） 
 RightTouch 4
5. © 2024 RightTouch Inc. アジェンダ 
 5 自己紹介・会社紹介 
 
 
 発表の目的と背景 
 
 
 フォーム実装の実際 

6. © 2024 RightTouch Inc. フォームの複雑性 
 6 我々の取り組むBtoB SaaSでは特に、業務要件を反映した複雑なフォームが必要な場面がある 
 一方、世の中に出ている事例はそれほど多くないのでは ?
 →本発表では、我々のプロダクト事例から、一つのフォーム設計の形を提示できればと思っています 
 シンプルなフォーム
 
 React-hook-formなどのライブラリ、または useState による管理で簡単に実装 
 複雑なフォーム
 
 編集対象オブジェクト・画面の特性 
 により最適な設計を都度考える必要性 
 • 編集対象オブジェクトの深いネスト 
 • 項目数の増加
 • 動的に変化する編集項目 
 • 項目をまたぐバリデーション 
 

7. © 2024 RightTouch Inc. RightTouchの具体例: サポートアクション 
 7 既存のお客様のWebサイトに、ノーコードで、パーソナライズされた 
 サポートコンテンツを埋め込むプロダクト 

8. © 2024 RightTouch Inc. RightTouchの具体例: サポートアクションオブジェクト 
 8 サポートアクションを表現するオブジェクトは 
 型定義だけで46ファイルに上る、ネストと配列を含む複雑なもの。 

9. © 2024 RightTouch Inc. RightTouchの具体例: サポートアクションオブジェクト 
 9 サポートアクションはパーツの組み合わせとして構成される。
 各パーツには、それぞれ様々なタイプが存在。プロダクトの進化とともにタイプはどんどん増えていく 
 Module ⾒出し Module FAQ Transition 秒数経過 Transition エラー表⽰ Component
 コーチマーク
 
 …
 …
 …
 SupportAction
 10秒経過
 エラー表示
 サポートアクションUI
 オブジェクト構造

10. © 2024 RightTouch Inc. RightTouchの具体例: サポートアクションエディタ 
 1 0 多数のパーツを 1画面で、リアルタイムプレ ビューつきで編集するフォーム 
 
 
 機能要件
 • 動的に変化する編集項目 
 • 各パーツをまたぐバリデーション 
 • 1画面に編集を収める 
 
 非機能要件
 • パーツの種類が増加しても、保守性、開 発生産性を維持できる 
 • パフォーマンスへの要求はそれほどシビ アではない

11. © 2024 RightTouch Inc. アジェンダ 
 1 1 自己紹介・会社紹介 
 
 
 発表の目的と背景 
 
 
 フォーム実装の実際 

12. © 2024 RightTouch Inc. フォームライブラリ : React Hook Formの採用
 1 2 編集対象オブジェクトのステート管理、バリデーションなどを一手に任せられる 
 生のuseStateなどの利用に比べ、コード量の大幅な削減が可能 
 ※類似のフォームライブラリもあるが、今後の安定性、複雑な型に対する適応力、我々の学習コスト等から今回は React Hook Formを採用
 ref: https://zenn.dev/manalink_dev/articles/winter-react-form-mokumoku-meetup-report

13. © 2024 RightTouch Inc. フォームライブラリ : React Hook Formの採用
 1 3 React Hook Formでは、オブジェクトの配列やネストといったある程度の複雑性への対処も可能 
 ドットでプロパティ名を繋ぐことにより、 
 ネストされたプロパティにアクセス可能 

14. © 2024 RightTouch Inc. ステート管理の分岐点 
 1 4 パーツ パーツ useForm
 丸ごとステート管理 
 オブジェクト全体を1つのuseFormで丸ごとステート管理するか、パーツごとに細分化するか？ 
 → 関心事をなるべく分け、個々のステートをシンプルにするため 開発当初数ヶ月は細分化する方式を採用 
 パーツ パーツ useForm
 useForm
 パーツごとにステート単位を細分化 

15. © 2024 RightTouch Inc. ステート細分化の弊害とリファクタ 
 1 5 要件の追加で別のパーツのデータやバリデーション結果を参照するニーズが増加。 
 異なるステート間を同期しあう苦しいコードが増える 
 → オブジェクト全体を丸ごと一つの useFormでステート管理する方式に変更 

16. © 2024 RightTouch Inc. オブジェクトを丸ごと React Hook Formでステート管理する際の課題 
 1 6 適切なReactコンポーネント分割
 型安全性とパフォーマンス 2
 1
 ステートは一つだが、 Reactコンポーネントはパーツごとに分解 し、その中ではあたかも小規模なフォームを開発しているように したい
 複雑なオブジェクトを React Hook Formで扱う場合、型計算に 限界が生じる部分がある。 

17. © 2024 RightTouch Inc. コンポーネント分割 
 1 7 useFormContextでpropsの過度なバケツリレーを避けつつ、 
 パーツごとに独立してフォームを記述していき、 Reactコンポーネントを小さく保つ 
 ※コードは簡略化したもの 

18. © 2024 RightTouch Inc. 型の課題1
 1 8 愚直にオブジェクト全体の型を useFormに入れると、型計算のコストがオブジェクトの複雑性に比例して増大 
 → 部分的にTypeScriptのコンパイル限界を超えてしまうことも 

19. © 2024 RightTouch Inc. 型の課題2
 1 9 ユニオンを含むオブジェクト をuseFormの型パラメータに指定すると、 
 React Hook Formの仕様上、プロパティアクセスを型安全に扱うことが難しい 
 ※コードは簡略化したもの 

20. © 2024 RightTouch Inc. サブタイプの利用による型課題の解決 
 2 0 各パーツごとに、そのパーツ専用の軽量な SupportAction型のサブタイプを定義
 useFormContextにはそれを渡すことで型計算のコストを低減、 スケール可能かつ型安全に 
 サブタイプ
 サブタイプ
 ※コードは簡略化したもの 

21. © 2024 RightTouch Inc. トレースの生成による型計算のボトルネック特定 
 2 1 tsc --generateTraceコマンドにより、tsコンパイル処理のトレースを取得 
 重い型計算がどこで行われているかを特定し、パフォーマンス改善を行う 

22. © 2024 RightTouch Inc. この方針で実装した結果 
 2 2 施策 good 施策 more • フォーム内でのデータの取り回しを簡便に⾏いつつ、Reactコンポーネントはモジュール 化し型安全に、という⽬論⾒は達成できている • 8ヵ⽉程度運⽤し、パーツの種類の追加も⼤きな問題なくスムーズに⾏えている • React Hook Formで巨⼤なオブジェクトを扱うにあたって、細かいライブラリのバグを踏 むこともあった(※) ※ https://github.com/react-hook-form/react-hook-form/issues/11937
23. © 2024 RightTouch Inc. まとめ
 2 3 • 複雑なオブジェクトのフォーム作成における設計事例を紹介 ◦ React Hook Formに⼯夫を加え、オブジェクト全体を管理させることで、バリデーションやステート 管理をライブラリに任せつつ、プラガブルにパーツを⾜していけるフォームを実装 ◦ 課題もまだあるものの、安定的に運⽤できている • 複雑なフォームであっても、なるべくシンプルな状態(=1ステートで丸ごと管理)から始めて、徐々に分割を 検討する⽅針の⽅が結果的には良かった • 今回のような⽅針はハマるケースとそうでないケースがある。下記要件によって⾒極める必要がある ◦ パーツ間のフォームの独⽴性 ◦ バリデーションの要件 ◦ フォームsubmitの形式とタイミング(e.g., ウィザード形式か1画⾯か)