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
96
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
190
複数人での 大規模サイト移植のテクニック
shumpei0111
1
900
個人開発者は Jamstackでブログを書こう!〜WordPressもいいけどJamstackもね〜
shumpei0111
0
130
Other Decks in Programming
See All in Programming
overlayPreferenceValue で実現する ピュア SwiftUI な AdMob ネイティブ広告
uhucream
0
180
大規模アプリのDIフレームワーク刷新戦略 ~過去最大規模の並行開発を止めずにアプリ全体に導入するまで~
mot_techtalk
1
450
Foundation Modelsを実装日本語学習アプリを作ってみた!
hypebeans
0
110
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
180
Devoxx BE - Local Development in the AI Era
kdubois
0
130
そのpreloadは必要?見過ごされたpreloadが技術的負債として爆発した日
mugitti9
2
3.4k
What's new in Spring Modulith?
olivergierke
1
150
Goで実践するドメイン駆動開発 AIと歩み始めた新規プロダクト開発の現在地
imkaoru
4
850
タスクの特性や不確実性に応じた最適な作業スタイルの選択(ペアプロ・モブプロ・ソロプロ)と実践 / Optimal Work Style Selection: Pair, Mob, or Solo Programming.
honyanya
3
180
エンジニアインターン「Treasure」とHonoの2年、そして未来へ / Our Journey with Hono Two Years at Treasure and Beyond
carta_engineering
0
280
TFLintカスタムプラグインで始める Terraformコード品質管理
bells17
2
200
Go Conference 2025: Goで体感するMultipath TCP ― Go 1.24 時代の MPTCP Listener を理解する
takehaya
9
1.7k
Featured
See All Featured
Practical Orchestrator
shlominoach
190
11k
BBQ
matthewcrist
89
9.8k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.6k
The Illustrated Children's Guide to Kubernetes
chrisshort
49
51k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
9
910
Building Adaptive Systems
keathley
44
2.8k
Building an army of robots
kneath
306
46k
The Cult of Friendly URLs
andyhume
79
6.6k
Writing Fast Ruby
sferik
629
62k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
35
6.1k
Raft: Consensus for Rubyists
vanstee
140
7.1k
Building a Scalable Design System with Sketch
lauravandoore
463
33k
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 ライフを 🎉