$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Reactで汎用的なinputコンポーネントを考える
Search
Shumpei O.
November 21, 2024
Programming
0
110
Reactで汎用的なinputコンポーネントを考える
2024.11.21
エンジニアコミュニティ内での登壇
Shumpei O.
November 21, 2024
Tweet
Share
More Decks by Shumpei O.
See All by Shumpei O.
Next.js で始めるセキュリティ入門
shumpei0111
0
7
例外処理について考える
shumpei0111
0
200
複数人での 大規模サイト移植のテクニック
shumpei0111
1
920
個人開発者は Jamstackでブログを書こう!〜WordPressもいいけどJamstackもね〜
shumpei0111
0
140
Other Decks in Programming
See All in Programming
JEP 496 と JEP 497 から学ぶ耐量子計算機暗号入門 / Learning Post-Quantum Crypto Basics from JEP 496 & 497
mackey0225
2
530
社内オペレーション改善のためのTypeScript / TSKaigi Hokuriku 2025
dachi023
1
300
非同期処理の迷宮を抜ける: 初学者がつまづく構造的な原因
pd1xx
1
390
Atomics APIを知る / Understanding Atomics API
ssssota
1
240
レイトレZ世代に捧ぐ、今からレイトレを始めるための小径
ichi_raven
0
490
GeistFabrik and AI-augmented software development
adewale
PRO
0
230
Level up your Gemini CLI - D&D Style!
palladius
1
150
Evolving NEWT’s TypeScript Backend for the AI-Driven Era
xpromx
0
240
乱雑なコードの整理から学ぶ設計の初歩
masuda220
PRO
32
15k
251126 TestState APIってなんだっけ?Step Functionsテストどう変わる?
east_takumi
0
290
アーキテクチャと考える迷子にならない開発者テスト
irof
9
3.4k
Socio-Technical Evolution: Growing an Architecture and Its Organization for Fast Flow
cer
PRO
0
180
Featured
See All Featured
Automating Front-end Workflow
addyosmani
1371
200k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
25
1.6k
Learning to Love Humans: Emotional Interface Design
aarron
274
41k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Docker and Python
trallard
46
3.7k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
Raft: Consensus for Rubyists
vanstee
140
7.2k
A Tale of Four Properties
chriscoyier
162
23k
Large-scale JavaScript Application Architecture
addyosmani
514
110k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
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 ライフを 🎉