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
Hyuga-Tsukui
January 12, 2023
Programming
490
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
190
非同期処理を使った応答性能改善 AWS Lambda
hyugatsukui
1
380
Other Decks in Programming
See All in Programming
Vite+ Unified Toolchain for the Web
naokihaba
0
240
AIで効率化できた業務・日常
ochtum
0
120
ローカルLLMを使ってB2Bサービスを作っていての学び
yaotti
0
160
AI 時代のソフトウェア設計の学び方
masuda220
PRO
29
12k
運用エージェントは "作る" から "育てる" へ - 記憶と自己進化の3層設計パターン / self-evolving-agents-three-layer-agent-design
gawa
12
3.6k
Oxlintのカスタムルールの現況
syumai
6
1.1k
Observability in Practice:Grafana 與 Edge Device SRE 的那些事
blueswen
0
160
DynamoDBには集計系のクエリがないけどなんとかしたい
musan
1
130
Datadog × OpenTelemetry 入門と実践のあいだ
kn_to_maxpno
1
150
The Arts and Crafts of Work in the AI Era — Toward Mastery in Software Development
kuranuki
1
750
Semantic Version 単位で戦略を柔軟に変えて、パッケージアップデートを自動化する
daitasu
0
200
[2026年度第1回ORセミナー] 計画最適化ベンチャーと競技プログラミング人材
terryu16
0
260
Featured
See All Featured
Highjacked: Video Game Concept Design
rkendrick25
PRO
1
390
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.9k
Rails Girls Zürich Keynote
gr2m
96
14k
Leading Effective Engineering Teams in the AI Era
addyosmani
9
2k
Balancing Empowerment & Direction
lara
6
1.2k
sira's awesome portfolio website redesign presentation
elsirapls
0
280
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.3k
The World Runs on Bad Software
bkeepers
PRO
72
12k
Side Projects
sachag
455
43k
Darren the Foodie - Storyboard
khoart
PRO
3
3.4k
Bootstrapping a Software Product
garrettdimon
PRO
307
120k
From π to Pie charts
rasagy
0
200
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がいい感 じに用意されてはいるが根底はこの仕組の差があるはず
まとめ
まとめ ・普段かんたんにライブラリを使うだけなら、あまり意識しないかもしれない部 分を改めて学習できた! ・非制御、制御の違いを知っていればハマったときに回避できるヒントになるか もしれない
ご清聴ありがとうございました!