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
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
190
非同期処理を使った応答性能改善 AWS Lambda
hyugatsukui
1
380
Other Decks in Programming
See All in Programming
Welcome to the "Parametricity" 🏙️ − Generic だけど Specific な世界 −
guvalif
PRO
1
180
act1-costs.pdf
sumedhbala
0
240
エンジニアにデザインハーネスを 〜デザインプロセスを規定するためのハーネス〜 / Design harness from an engineer's perspective
rkaga
2
1.6k
AI時代、エンジニアはどう育つのか -未経験エンジニアの成長を間近で見て考えたこと-
thasu0123
0
140
初めてのKubernetes 本番運用でハマった話
oku053
0
130
SLOをサービス品質の共通言語にするために 取り組んできたこと
wakana0222
0
540
Foundation Models frameworkで画像分析
ryodeveloper
1
130
Laravel Boostに学ぶ、AIにPHPを書かせる技術 〜OSSの実装から蒸留するエージェント制御の王道〜
kentaroutakeda
3
510
AWS CDK を「作」ってみた 〜フルスクラッチで見えた CDK の裏側〜 / aws-cdk-from-scratch
gotok365
3
480
鹿野さんに聞く!『TypeScriptコードレシピ集』で磨く実践力
tonkotsuboy_com
4
1.1k
えっ!!コードを読まずに開発を!?
hananouchi
0
230
【やさしく解説 設計編 #0】DDDのコード、読めるのに分からない人へ
panda728
PRO
2
270
Featured
See All Featured
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
3
1k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.5k
Reality Check: Gamification 10 Years Later
codingconduct
0
2.2k
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct
2
420
Raft: Consensus for Rubyists
vanstee
141
7.6k
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
410
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
370
A Tale of Four Properties
chriscoyier
163
24k
Navigating the moral maze — ethical principles for Al-driven product design
skipperchong
2
420
Breaking role norms: Why Content Design is so much more than writing copy - Taylor Woolridge
uxyall
0
350
30 Presentation Tips
portentint
PRO
1
350
Google's AI Overviews - The New Search
badams
0
1.1k
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がいい感 じに用意されてはいるが根底はこの仕組の差があるはず
まとめ
まとめ ・普段かんたんにライブラリを使うだけなら、あまり意識しないかもしれない部 分を改めて学習できた! ・非制御、制御の違いを知っていればハマったときに回避できるヒントになるか もしれない
ご清聴ありがとうございました!