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
4
620
複雑性の高いオブジェクト編集に向き合う: プラガブルな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
プロダクト志向ってなんなんだろうね
righttouch
PRO
0
210
RightTouch Company Deck ver1.0
righttouch
PRO
4
18k
小規模組織のプロダクトエンジニアとして、アンラーニングしたこと
righttouch
PRO
4
830
3rd party scriptでもReactを使いたい! Preact + Reactのハイブリッド開発
righttouch
PRO
5
1.1k
カスタマーサポート市場の改革に挑む 急成長中のプロダクトエンジニアチームの挑戦と舞台裏
righttouch
PRO
5
580
Webカスタマーサポート向けSaaSにおけるLLMの活用
righttouch
PRO
5
1.3k
機能リプレースで進化する: フロントエンドの刷新とサーバーモデルのリファクタリング
righttouch
PRO
4
540
Other Decks in Technology
See All in Technology
P2P ではじめる WebRTC のつまづきどころ
tnoho
1
220
メモ整理が苦手な者による頑張らないObsidian活用術
optim
0
130
機械学習を「社会実装」するということ 2025年夏版 / Social Implementation of Machine Learning July 2025 Version
moepy_stats
1
780
分散トレーシングによる コネクティッドカーのデータ処理見える化の試み
thatsdone
0
240
AIを使っていい感じにE2Eテストを書けるようになるまで / Trying to Write Good E2E Tests with AI
katawara
3
1.7k
20250719_JAWS_kobe
takuyay0ne
1
160
Jitera Company Deck / JP
jitera
0
160
MCP とマネージド PaaS で実現する大規模 AI アプリケーションの高速開発
nahokoxxx
1
1.6k
Recoil脱却の現状と挑戦
kirik
3
380
スプリントレビューを効果的にするために
miholovesq
9
1.6k
MCPに潜むセキュリティリスクを考えてみる
milix_m
1
780
AI時代の知識創造 ─GeminiとSECIモデルで読み解く “暗黙知”と創造の境界線
nyagasan
0
130
Featured
See All Featured
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
BBQ
matthewcrist
89
9.7k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
990
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
We Have a Design System, Now What?
morganepeng
53
7.7k
How to Ace a Technical Interview
jacobian
278
23k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
A Modern Web Designer's Workflow
chriscoyier
695
190k
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