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で汎用的なinputコンポーネントを考える
Search
Shumpei O.
November 21, 2024
Programming
0
11
Reactで汎用的なinputコンポーネントを考える
2024.11.21
エンジニアコミュニティ内での登壇
Shumpei O.
November 21, 2024
Tweet
Share
More Decks by Shumpei O.
See All by Shumpei O.
例外処理について考える
shumpei0111
0
80
複数人での 大規模サイト移植のテクニック
shumpei0111
1
740
個人開発者は Jamstackでブログを書こう!〜WordPressもいいけどJamstackもね〜
shumpei0111
0
84
Other Decks in Programming
See All in Programming
Запуск 1С:УХ в крупном энтерпрайзе: мечта и реальность ПМа
lamodatech
0
870
Оптимизируем производительность блока Казначейство
lamodatech
0
880
テストコード書いてみませんか?
onopon
2
290
Go の GC の不得意な部分を克服したい
taiyow
3
980
iOS開発におけるCopilot For XcodeとCode Completion / copilot for xcode
fuyan777
1
1.2k
Внедряем бюджетирование, или Как сделать хорошо?
lamodatech
0
860
テストケースの名前はどうつけるべきか?
orgachem
PRO
1
180
技術的負債と向き合うカイゼン活動を1年続けて分かった "持続可能" なプロダクト開発
yuichiro_serita
0
270
開発者とQAの越境で自動テストが増える開発プロセスを実現する
92thunder
1
220
どうして手を動かすよりもチーム内のコードレビューを優先するべきなのか
okashoi
3
810
Androidアプリのモジュール分割における:x:commonを考える
okuzawats
1
260
生成AIでGitHubソースコード取得して仕様書を作成
shukob
0
600
Featured
See All Featured
Thoughts on Productivity
jonyablonski
68
4.4k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
26
1.9k
Adopting Sorbet at Scale
ufuk
74
9.1k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
Code Reviewing Like a Champion
maltzj
521
39k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
4 Signs Your Business is Dying
shpigford
182
21k
Navigating Team Friction
lara
183
15k
Bash Introduction
62gerente
609
210k
How to Ace a Technical Interview
jacobian
276
23k
Transcript
Reactで汎用的な input コンポーネントを考える Shumpei / 2024.11.21
目次 1. 今日のゴール 2. 結論 3. useIdでアクセシブルにする 4. なるべく自分で型を書かない
目次 1. 今日のゴール 2. 結論 3. useIdでアクセシブルにする 4. なるべく自分で型を書かない
今日のゴール 01. useId という組み込みの React フックを使って、 label と input の紐づけを行う実装例を知ることができる
02. 型定義もなるべくReact や TypeScript がすでに用意しているものを 使い、自分で作らないようにする実装例を知ることができる
目次 1. 今日のゴール 2. 結論 3. useIdでアクセシブルにする 4. なるべく自分で型を書かない
結論 01. input はどこで何個使われるかわからないので、 useId も使って、 重複した id が発生しないようにしよう 02.
InputHTMLAttributes や ComponentProps などを使って、 なるべく自分で書かないで保守性を高めよう
目次 1. 今日のゴール 2. 結論 3. useIdでアクセシブルにする 4. なるべく自分で型を書かない
useId でアクセシブルにする useId は React が提供する、アクセシビリティを高めるためのフックです。 https://ja.react.dev/reference/react/useId
useId でアクセシブルにする useId は React が提供する、アクセシビリティを高めるためのフックです。 https://ja.react.dev/reference/react/useId どんな時に使うかと言うと、 input と
label を組み合わせた コンポーネントを作るときなどが 良いと考えています。
おさらい input タグは、 label タグと紐づけることができます。 ブラウザは input タグの id と
label の for 属性(React では htmlFor )が 同じ場合、関連するものとして認識します。
おさらい 関連した組の場合、label をクリックすると 関連した input にフォーカスがあたります。 人はまずラベルが目に入り触ろうとするので、 UX の観点からも紐づけてあげることが よりよいアクセシビリティに繋がります。
なぜ useId を使うのか React を使うと部品単位でコンポーネントを作り、 組み合わせて画面を作ります。 どこで何個使うかわからないため、素朴に props で id
を受け取るだけだと 被ってしまう可能性があります。 label と input を組み合わせた React コンポーネントが 気づかずに重複した id を渡してしまう可能性がある
Q. id が被ってしまうのはなぜ悪いのか A. HTMLのルールだから。 id グローバル属性は、文書全体で一意でなければならない識別子 (ID) を定義します。 引用:MDN
(https://developer.mozilla.org/ja/docs/Web/HTML/Global_attributes/id)
Q. 被ったらどうなるの? 表面上、ただちに何か問題になることはありません。 が、重複した id を持つ入力フォームが1つの画面にある場合、 先頭のものがフォーカスの対象になります。 もし「歯磨きした?」ラベルをクリックしても 自分が思っている入力欄にフォーカスが当たらないので、 ユーザは混乱してしまう
useId を使ってユニークな id を自動で生成させる この React フックを使えば自動的にユニークな id を提供してくれるので、 重複することがなく、HTML
のルールから外れることはありません。
useId を使ってユニークな id を自動で生成させる useId は例えば :r1: のようなただの文字列を提供するだけなので、 プレフィックスをつけたりなどして、生成された HTML
から管理しやすく できる余地もあります。
目次 1. 今日のゴール 2. 結論 3. useIdでアクセシブルにする 4. なるべく自分で型を書かない
なるべく自分で型を書かない React / TypeScript は、一般的な HTML タグに関わる型定義や、 コンポーネント独自に定義した型情報を便利に使い回せるユーティリティな型を用 意しています。
なるべく自分で型を書かない メリットとしては、DRY に書けることや、型指定のヌケモレが減らせるようなメンテナ ンス性の向上などが期待できます。
ComponentProps<T> を使う React が提供する型。 /node_modules/@types/react/index.d.ts で確認可能です。 コンポーネントがすでに定義している型 (propsでどんな型を受け取るのかなど)を利用することができます。 https://react-typescript-cheatsheet.netlify.app/docs/react-types/componentprops/
ComponentProps<T> を使う MUI や shadcn/ui などのUIライブラリのコンポーネントと、 独自の型を組み合わせたベースのコンポーネントの型を使いまわしたい。 そんな時に使えます。
ComponentProps<T> を使う メリット カスタムコンポーネントやHTML 要素の型を再利用する場合に 一貫性が担保される デメリット 複雑な定義をするのには向いていない。 ref
を含むすべての props を含むので、組み合わせによっては不要な型情報も 含まれる可能性がある。
ComponentProps<T> を使う メリット カスタムコンポーネントやHTML 要素の型を再利用する場合に 一貫性が担保される デメリット 複雑な定義をするのには向いていない。 ref
を含むすべての props を含むので、組み合わせによっては不要な型情報も 含まれる可能性がある。 ▶ ref の扱いを明示的に行う ComponentPropsWithRef / ComponentPropsWithoutRef という型もあるので適宜検討す る。
ComponentProps<T> を使う
HTMLXXXElement を使う TypeScript が提供する型。 /node_modules/typescript/lib/lib.dom.d.ts で確認可能です。 ブラウザが定義している各HTMLタグが受け取れる属性情報がすでに定義されて います。 例えば button
タグなどは自分で定義せず HTMLButtonElement を使うことでメン テナンスコストを下げられます。
HTMLXXXElement を使う
まとめ • useId を使って input と label を紐づけるようにする • React
/ TypeScript を使って再利用性の高い型定義を心がける
まとめ よき React ライフを 🎉