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
98
複雑性の高いオブジェクト編集に向き合う: プラガブルな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
720
カスタマーサポート市場の改革に挑む 急成長中のプロダクトエンジニアチームの挑戦と舞台裏
righttouch
PRO
1
440
Webカスタマーサポート向けSaaSにおけるLLMの活用
righttouch
PRO
1
1k
機能リプレースで進化する: フロントエンドの刷新とサーバーモデルのリファクタリング
righttouch
PRO
0
450
Other Decks in Technology
See All in Technology
OpenAIの蒸留機能(Model Distillation)を使用して運用中のLLMのコストを削減する取り組み
pharma_x_tech
3
410
OpsJAWS32 re:Invent 2024 Ops系アップデートまとめ
takahirohori
0
190
GPTsで模擬問題生成して資格対策してみる
hsg_alf
2
120
re:Invent をおうちで楽しんでみた ~CloudWatch のオブザーバビリティ機能がスゴい!/ Enjoyed AWS re:Invent from Home and CloudWatch Observability Feature is Amazing!
yuj1osm
0
110
How to be an AWS Community Builder | 君もAWS Community Builderになろう!〜2024 冬 CB募集直前対策編?!〜
coosuke
PRO
2
2.6k
5分でわかるDuckDB
chanyou0311
9
3.1k
サイボウズフロントエンドエキスパートチームについて / FrontendExpert Team
cybozuinsideout
PRO
5
38k
AI時代のデータセンターネットワーク
lycorptech_jp
PRO
1
250
『GRANBLUE FANTASY: Relink』続・最高の「没入感」を実現するカットシーン制作手法とそれを支える技術
cygames
0
130
GitHub Copilot のテクニック集/GitHub Copilot Techniques
rayuron
11
3.5k
Classmethod_regrowth_2024_tokyo_security_identity_governance_summary
hiashisan
0
970
ブラックフライデーで購入したPixel9で、Gemini Nanoを動かしてみた
marchin1989
1
380
Featured
See All Featured
Gamification - CAS2011
davidbonilla
80
5.1k
Embracing the Ebb and Flow
colly
84
4.5k
Statistics for Hackers
jakevdp
796
220k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
BBQ
matthewcrist
85
9.4k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Raft: Consensus for Rubyists
vanstee
136
6.7k
Become a Pro
speakerdeck
PRO
26
5k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Making the Leap to Tech Lead
cromwellryan
133
9k
It's Worth the Effort
3n
183
28k
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