Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
複雑性の高いオブジェクト編集に向き合う: プラガブルなReactフォーム設計
Search
RightTouch
PRO
December 12, 2024
Technology
0
110
複雑性の高いオブジェクト編集に向き合う: プラガブルなReactフォーム設計
2024/12/12 ~Tech-Front Meetup~ 一歩先のフロントエンドへ 登壇資料
https://levtechcareer.connpass.com/event/337755/
RightTouch
PRO
December 12, 2024
Tweet
Share
More Decks by RightTouch
See All by RightTouch
3rd party scriptでもReactを使いたい! Preact + Reactのハイブリッド開発
righttouch
PRO
1
730
カスタマーサポート市場の改革に挑む 急成長中のプロダクトエンジニアチームの挑戦と舞台裏
righttouch
PRO
1
450
Webカスタマーサポート向けSaaSにおけるLLMの活用
righttouch
PRO
1
1k
機能リプレースで進化する: フロントエンドの刷新とサーバーモデルのリファクタリング
righttouch
PRO
0
450
Other Decks in Technology
See All in Technology
kargoの魅力について伝える
magisystem0408
0
200
UI State設計とテスト方針
rmakiyama
2
440
How to be an AWS Community Builder | 君もAWS Community Builderになろう!〜2024 冬 CB募集直前対策編?!〜
coosuke
PRO
2
2.8k
Postman と API セキュリティ / Postman and API Security
yokawasa
0
200
20241214_WACATE2024冬_テスト設計技法をチョット俯瞰してみよう
kzsuzuki
3
440
フロントエンド設計にモブ設計を導入してみた / 20241212_cloudsign_TechFrontMeetup
bengo4com
0
1.9k
レンジャーシステムズ | 会社紹介(採用ピッチ)
rssytems
0
150
Wantedly での Datadog 活用事例
bgpat
1
430
大幅アップデートされたRagas v0.2をキャッチアップ
os1ma
2
520
Wvlet: A New Flow-Style Query Language For Functional Data Modeling and Interactive Data Analysis - Trino Summit 2024
xerial
1
110
マルチプロダクト開発の現場でAWS Security Hubを1年以上運用して得た教訓
muziyoshiz
2
2.2k
サーバレスアプリ開発者向けアップデートをキャッチアップしてきた #AWSreInvent #regrowth_fuk
drumnistnakano
0
190
Featured
See All Featured
Fireside Chat
paigeccino
34
3.1k
Adopting Sorbet at Scale
ufuk
73
9.1k
The Pragmatic Product Professional
lauravandoore
32
6.3k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
28
2.1k
Practical Orchestrator
shlominoach
186
10k
Why Our Code Smells
bkeepers
PRO
335
57k
Making the Leap to Tech Lead
cromwellryan
133
9k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
The Cost Of JavaScript in 2023
addyosmani
45
7k
The Power of CSS Pseudo Elements
geoffreycrofte
73
5.4k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Music & Morning Musume
bryan
46
6.2k
Transcript
複雑性の高いオブジェクト編集に向き合う プラガブルな Reactフォーム設計 @2024/12/12 ~Tech-Front Meetup~ 一歩先のフロントエンドへ
1
© 2024 RightTouch Inc. アジェンダ 2 自己紹介・会社紹介
発表の目的と背景 フォーム実装の実際
© 2024 RightTouch Inc. 3 自己紹介 2020 東京大学理学系研究科博士課程修了
2020-2021 日立製作所 2021-2024 株式会社プレイド 2021-現在 株式会社RightTouch レーザー物理で博士号取得後、日立製作所で ITプラットフォームの設 計・開発に従事。 その後、プレイド/RightTouchで、テックリード/フルスタックエンジニア としてアプリケーション開発に従事。 好きなもの: 旬 齋藤 成之 X: @nakaakist
© 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
© 2024 RightTouch Inc. アジェンダ 5 自己紹介・会社紹介
発表の目的と背景 フォーム実装の実際
© 2024 RightTouch Inc. フォームの複雑性 6 我々の取り組むBtoB SaaSでは特に、業務要件を反映した複雑なフォームが必要な場面がある
一方、世の中に出ている事例はそれほど多くないのでは ? →本発表では、我々のプロダクト事例から、一つのフォーム設計の形を提示できればと思っています シンプルなフォーム React-hook-formなどのライブラリ、または useState による管理で簡単に実装 複雑なフォーム 編集対象オブジェクト・画面の特性 により最適な設計を都度考える必要性 • 編集対象オブジェクトの深いネスト • 項目数の増加 • 動的に変化する編集項目 • 項目をまたぐバリデーション
© 2024 RightTouch Inc. RightTouchの具体例: サポートアクション 7 既存のお客様のWebサイトに、ノーコードで、パーソナライズされた
サポートコンテンツを埋め込むプロダクト
© 2024 RightTouch Inc. RightTouchの具体例: サポートアクションオブジェクト 8 サポートアクションを表現するオブジェクトは
型定義だけで46ファイルに上る、ネストと配列を含む複雑なもの。
© 2024 RightTouch Inc. RightTouchの具体例: サポートアクションオブジェクト 9 サポートアクションはパーツの組み合わせとして構成される。 各パーツには、それぞれ様々なタイプが存在。プロダクトの進化とともにタイプはどんどん増えていく
Module ⾒出し Module FAQ Transition 秒数経過 Transition エラー表⽰ Component コーチマーク … … … SupportAction 10秒経過 エラー表示 サポートアクションUI オブジェクト構造
© 2024 RightTouch Inc. RightTouchの具体例: サポートアクションエディタ 1 0 多数のパーツを
1画面で、リアルタイムプレ ビューつきで編集するフォーム 機能要件 • 動的に変化する編集項目 • 各パーツをまたぐバリデーション • 1画面に編集を収める 非機能要件 • パーツの種類が増加しても、保守性、開 発生産性を維持できる • パフォーマンスへの要求はそれほどシビ アではない
© 2024 RightTouch Inc. アジェンダ 1 1 自己紹介・会社紹介
発表の目的と背景 フォーム実装の実際
© 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
© 2024 RightTouch Inc. フォームライブラリ : React Hook Formの採用 1
3 React Hook Formでは、オブジェクトの配列やネストといったある程度の複雑性への対処も可能 ドットでプロパティ名を繋ぐことにより、 ネストされたプロパティにアクセス可能
© 2024 RightTouch Inc. ステート管理の分岐点 1 4 パーツ パーツ
useForm 丸ごとステート管理 オブジェクト全体を1つのuseFormで丸ごとステート管理するか、パーツごとに細分化するか? → 関心事をなるべく分け、個々のステートをシンプルにするため 開発当初数ヶ月は細分化する方式を採用 パーツ パーツ useForm useForm パーツごとにステート単位を細分化
© 2024 RightTouch Inc. ステート細分化の弊害とリファクタ 1 5 要件の追加で別のパーツのデータやバリデーション結果を参照するニーズが増加。
異なるステート間を同期しあう苦しいコードが増える → オブジェクト全体を丸ごと一つの useFormでステート管理する方式に変更
© 2024 RightTouch Inc. オブジェクトを丸ごと React Hook Formでステート管理する際の課題 1
6 適切なReactコンポーネント分割 型安全性とパフォーマンス 2 1 ステートは一つだが、 Reactコンポーネントはパーツごとに分解 し、その中ではあたかも小規模なフォームを開発しているように したい 複雑なオブジェクトを React Hook Formで扱う場合、型計算に 限界が生じる部分がある。
© 2024 RightTouch Inc. コンポーネント分割 1 7 useFormContextでpropsの過度なバケツリレーを避けつつ、
パーツごとに独立してフォームを記述していき、 Reactコンポーネントを小さく保つ ※コードは簡略化したもの
© 2024 RightTouch Inc. 型の課題1 1 8 愚直にオブジェクト全体の型を useFormに入れると、型計算のコストがオブジェクトの複雑性に比例して増大
→ 部分的にTypeScriptのコンパイル限界を超えてしまうことも
© 2024 RightTouch Inc. 型の課題2 1 9 ユニオンを含むオブジェクト をuseFormの型パラメータに指定すると、
React Hook Formの仕様上、プロパティアクセスを型安全に扱うことが難しい ※コードは簡略化したもの
© 2024 RightTouch Inc. サブタイプの利用による型課題の解決 2 0 各パーツごとに、そのパーツ専用の軽量な SupportAction型のサブタイプを定義
useFormContextにはそれを渡すことで型計算のコストを低減、 スケール可能かつ型安全に サブタイプ サブタイプ ※コードは簡略化したもの
© 2024 RightTouch Inc. トレースの生成による型計算のボトルネック特定 2 1 tsc --generateTraceコマンドにより、tsコンパイル処理のトレースを取得
重い型計算がどこで行われているかを特定し、パフォーマンス改善を行う
© 2024 RightTouch Inc. この方針で実装した結果 2 2 施策 good
施策 more • フォーム内でのデータの取り回しを簡便に⾏いつつ、Reactコンポーネントはモジュール 化し型安全に、という⽬論⾒は達成できている • 8ヵ⽉程度運⽤し、パーツの種類の追加も⼤きな問題なくスムーズに⾏えている • React Hook Formで巨⼤なオブジェクトを扱うにあたって、細かいライブラリのバグを踏 むこともあった(※) ※ https://github.com/react-hook-form/react-hook-form/issues/11937
© 2024 RightTouch Inc. まとめ 2 3 • 複雑なオブジェクトのフォーム作成における設計事例を紹介 ◦
React Hook Formに⼯夫を加え、オブジェクト全体を管理させることで、バリデーションやステート 管理をライブラリに任せつつ、プラガブルにパーツを⾜していけるフォームを実装 ◦ 課題もまだあるものの、安定的に運⽤できている • 複雑なフォームであっても、なるべくシンプルな状態(=1ステートで丸ごと管理)から始めて、徐々に分割を 検討する⽅針の⽅が結果的には良かった • 今回のような⽅針はハマるケースとそうでないケースがある。下記要件によって⾒極める必要がある ◦ パーツ間のフォームの独⽴性 ◦ バリデーションの要件 ◦ フォームsubmitの形式とタイミング(e.g., ウィザード形式か1画⾯か)
24