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
Form実装基本を学び直してみた
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
Hyuga-Tsukui
January 12, 2023
Programming
500
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Form実装基本を学び直してみた
https://anotherworks.connpass.com/event/270238/
Hyuga-Tsukui
January 12, 2023
More Decks by Hyuga-Tsukui
See All by Hyuga-Tsukui
エンジニアリングの本質を見極めて、何気ない行動の質を上げよう
hyugatsukui
0
200
非同期処理を使った応答性能改善 AWS Lambda
hyugatsukui
1
390
Other Decks in Programming
See All in Programming
AIに既存システムを理解させる技術 ~レガシーを見捨てないハーネスエンジニアリング入門~
ochtum
0
150
リアルな遅延を測る仕様
kota_yata
1
130
Go 1.27からのGODEBUG / Go 1.27 リリースパーティ #go127party
mazrean
0
220
仕様書を書く前にハーネスを作る - Agent Native開発は「探索を速く、判定を固く」
gotalab555
4
1.8k
私のClaude Code活用法 (個人開発編) - PHPerKaigi mini #4(2026/08/24)
panda_program
1
160
【デモ】Kiroで体験する仕様駆動開発|設計からコーディングまでAIと進める開発フロー
cmkudo
0
400
AI Engineeringは、AIプロダクトだけのものか? 〜AIがソフトウェアを作る時代の新しい当たり前〜 / No AI in your product. AI Engineering in your development.
rkaga
5
530
komatsuna「分散システムにおけるバグ分析手法」
komatsunaqa
0
280
Press start. Python's next generation.
willingc
PRO
3
160
「つくるAI」だけではバグは見つからない ~テストに必要な「見つけるAI」を分離させる戦略~
mfunaki
0
180
いまどきの Codex で開発する visionOS アプリの開発スタイルについて
karad
0
160
Go 1.27 における memory allocation の高速化
andpad
0
330
Featured
See All Featured
Code Review Best Practice
trishagee
74
20k
Building the Perfect Custom Keyboard
takai
2
850
The Limits of Empathy - UXLibs8
cassininazir
1
620
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
The Illustrated Guide to Node.js - THAT Conference 2024
reverentgeek
1
440
Optimizing for Happiness
mojombo
378
71k
Winning Ecommerce Organic Search in an AI Era - #searchnstuff2025
aleyda
1
2.1k
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
210
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
1
2.5k
RailsConf 2023
tenderlove
30
1.5k
Raft: Consensus for Rubyists
vanstee
141
7.6k
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
870
Transcript
Form実装基本を学び直して みた! 制御・非制御コンポーネントを意識しながら React Tech Night TOKYO@株式会社Another works主催 Speaker@Hyuga-Tsukui
・Hyuga-Tsukui (@hy_twenで活動中です!) ・最近27歳になってしまいました! ・シェルフィー株式会社でエンジニアとして在籍(主にバックエンド) ・Java,Kotlin,TypeScript,Python ・React,Spring,Django 自己紹介
はじめに
UI・UXとしてのFormはこうだといった、ユーザ体験ベースの話題ではありませ ん! ReactでFormを実装する時の実装観点での基本を私が学びなおしたお話で す! 題材的に初歩的内容かと思うので、知見や間違いの指摘は大歓迎です!(く れたら泣いて喜びます 😂 例としてライブラリが出ますが、ライブラリを主題としてはいません! はじめに
きっかけ
きっかけ ・私がReact Hook FormからReactでのForm実装に入門した ・どうやらFormilkなるものの時代もあったようだ ・大きく差がついた(?)両者のアプローチの違いなどが気になった
formik vs react-hook-form
少し脱線してしまったので本題へ 本題へ
・rhfは非制御コンポーネントの利用をベースとしたAPIでのアプローチ ・Formilkは制御コンポーネントベースのAPIでのアプローチ ・とはいえ非制御・制御の違いを知るとどちらが悪いとかは無いだろうと思える 超結論
少し脱線してしまったので本題へ ところで制御・非制御って?
公式の引用
制御されたコンポーネント HTML では <input>、<textarea>、そして <select> のようなフォーム要素は通常、自身で状態を保持しており、 ユーザの入力に基づいてそれを更新します。 React では、変更されうる状態は通常はコンポーネントの state
プロパ ティに保持され、setState() 関数でのみ更新されます。 React の state を “信頼できる唯一の情報源 (single source of truth)” とすることで、上述の 2 つの状態を結合させ ることができます。そうすることで、フォームをレンダーしている React コンポーネントが、後続するユーザ入力で フォームで起きることも制御できるようになります。このような方法で React によって値が制御される入力フォーム要 素は「制御されたコンポーネント」と呼ばれます。 https://ja.reactjs.org/docs/forms.html#controll ed-components
あるローカルな状態を持つコンポーネントを「非制御」と呼ぶのはよくあることです。例えば、 isActive状態変数を持つオリジナルのPanelコンポーネントは、その親がパネルがアクティブかどう かに影響できないので、非制御型です。 これに対して、コンポーネント内の重要な情報が、それ自身のローカル状態ではなく、propsによっ て駆動される場合、コンポーネントを「controlled」と呼ぶことができます。これにより、親コンポーネ ントがその動作を完全に指定することができます。最終的にisActiveプロップを持つPanelコンポー ネントは、Accordionコンポーネントによって制御されます。(一部抜粋&Deeple翻訳) Controlled and uncontrolled
components https://beta.reactjs.org/learn/sharing-state-be tween-components#controlled-and-uncontroll ed-components
私の理解
制御で実装している例
None
このStateが
このStateが inputコンポーネントのPropsに渡さ れて
このStateが inputコンポーネントのPropsに渡さ れて onChangeで状態が変化し、 ReactiveにUIが制御されている
制御されたコンポーネント HTML では <input>、<textarea>、そして <select> のようなフォーム要素は通常、自身で状態を保持しており、 ユーザの入力に基づいてそれを更新します。 React では、変更されうる状態は通常はコンポーネントの state
プロパ ティに保持され、setState() 関数でのみ更新されます。 React の state を “信頼できる唯一の情報源 (single source of truth)” とすることで、上述の 2 つの状態を結合させ ることができます。そうすることで、フォームをレンダーしている React コンポーネントが、後続するユーザ入力で フォームで起きることも制御できるようになります。このような方法で React によって値が制御される入力フォーム要 素は「制御されたコンポーネント」と呼ばれます。 https://ja.reactjs.org/docs/forms.html#controll ed-components
あるローカルな状態を持つコンポーネントを「非制御」と呼ぶのはよくあることです。例えば、 isActive状態変数を持つオリジナルのPanelコンポーネントは、その親がパネルがアクティブかどう かに影響できないので、非制御型です。 これに対して、コンポーネント内の重要な情報が、それ自身のローカル状態ではなく、propsによっ て駆動される場合、コンポーネントを「controlled」と呼ぶことができます。これにより、親コンポーネ ントがその動作を完全に指定することができます。最終的にisActiveプロップを持つPanelコンポー ネントは、Accordionコンポーネントによって制御されます。(一部抜粋&Deeple翻訳) Controlled and uncontrolled
components https://beta.reactjs.org/learn/sharing-state-be tween-components#controlled-and-uncontroll ed-components
非制御で実装している例
None
一般に、DOMで管理された値を取 得するためにRefを生成します
一般に、DOMで管理された値を取得す るためにRefを生成します Propsを渡していない
制御されたコンポーネント HTML では <input>、<textarea>、そして <select> のようなフォーム要素は通常、自身で状態を保持しており、 ユーザの入力に基づいてそれを更新します 。React では、変更されうる状態は通常はコンポーネントの state
プロパ ティに保持され、setState() 関数でのみ更新されます。 React の state を “信頼できる唯一の情報源 (single source of truth)” とすることで、上述の 2 つの状態を結合させ ることができます。そうすることで、フォームをレンダーしている React コンポーネントが、後続するユーザ入力で フォームで起きることも制御できるようになります。このような方法で React によって値が制御される入力フォーム要 素は「制御されたコンポーネント」と呼ばれます。 https://ja.reactjs.org/docs/forms.html#controll ed-components
あるローカルな状態を持つコンポーネントを「非制御」と呼ぶのはよくあることです。例えば、 isActive状態変数を持つオリジナルのPanelコンポーネントは、その親がパネルがアクティブかどう かに影響できないので、非制御型です。 これに対して、コンポーネント内の重要な情報が、それ自身のローカル状態ではなく、propsによっ て駆動される場合、コンポーネントを「controlled」と呼ぶことができます。これにより、親コンポーネ ントがその動作を完全に指定することができます。最終的にisActiveプロップを持つPanelコンポー ネントは、Accordionコンポーネントによって制御されます。(一部抜粋&Deeple翻訳) Controlled and uncontrolled
components https://beta.reactjs.org/learn/sharing-state-be tween-components#controlled-and-uncontroll ed-components
私の理解 ・Propsによって状態が制御されているのが制御コンポーネント ・逆にPropsでないつまり、親から渡されたものではないローカルだけの状態コ ンポーネントが非制御コンポーネント
Form実装におけるそれぞれの違い
Form実装時のそれぞれの得意ポイント https://goshacmd.com/controlled-vs-uncontrolled-inputs-react/
この違いはどこから生まれるか ・入力にReactiveに反応できるかどうか ・信頼できる唯一の情報源 (single source of truth)かどうか
https://f-tra.com/ja/blog/column/7036
UXとして右が良いというのはおいておい て。。。
https://f-tra.com/ja/blog/column/7036 ここの入力によって
https://f-tra.com/ja/blog/column/7036 ここの入力によって ここを制御する
https://f-tra.com/ja/blog/column/7036 ここの入力によって ここを制御する
制御の場合
None
zipCodeを受け取る
zipCodeを受け取る 状態が変わるので、再レンダリング
zipCodeを受け取る 状態が変わるので、再レンダリング 条件によりEffect内のCBが実行、 AddressがReactiveに設定される
非制御の場合
None
制御下にないローカルな DOMの値を 操作するためにRefを用意
制御下にないローカルな DOMの値を 操作するためにRefを用意 zipCodeのBlurEventで変更を検知 し、Refを通して直接更新
この違いはどこから生まれるか ・入力にReactiveに反応できるかどうか ・信頼できる唯一の情報源 (single source of truth)かどうか
どちらが良いとかいうわけではないはず。。 ・制御 ・非制御にくらべ多くのレンダリングを発生させる可能性が有る ・Reactの思想に沿っているので宣言的な記述になりやすい ・非制御 ・制御に比べレンダリングを抑制しやすい ・インスタントな検証など即時反応したいケースを実装することがし辛い(複雑になる、refの操作など、ライブラリ使っ た場合も後述)
react-hook-formに触れる ・modeにonChange modeがあったり(制御になる) ・watchやgetValue,setValueなどローカルな状態を変更させるAPIがいい感 じに用意されてはいるが根底はこの仕組の差があるはず
まとめ
まとめ ・普段かんたんにライブラリを使うだけなら、あまり意識しないかもしれない部 分を改めて学習できた! ・非制御、制御の違いを知っていればハマったときに回避できるヒントになるか もしれない
ご清聴ありがとうございました!