なぜ <div> に onClick がダメなのか？
■ はじめに <div>要素にonClickを渡すべきではない、ということ聞いたことはないでしょうか？ ただ、なぜ渡すべきでないのか？ 理解してなかったので今回調べてみました。 サンプルコード 今回動作確認に利用したサンプルリポジトリのコードはReactで書いています。 ■ 結論：<div>にonClickを定義するのがなぜダメなのか？ ユーザーにとって操作性の低いボタンになってしまうから、です！ 要するに UX が悪くなってしまうから！ その理由を解説していきます！ ■ 操作性の低いボタンになってしまう理由 大きく３つあると考えています。 div要素は focus を持たないから returnキー, spaceキーをonClickに変換しないから スクリーンリーダーが認識しない要素だから ◎ focus を持たないから <div>要素はfocusを持ちません。 なので、tabキーで要素に
今後の React ではどの範囲を Suspense で囲むかという設計が重要になってくる
はじめに 今後のReactではどの範囲をSuspenseで囲むか という設計が重要になってくる、という話をSuspenseの説明とともにしていきます！ ※React18がリリースされて１年近く経つので今更感あるかもしれませんが、お付き合いください。 Suspense とは React18で正式な機能として実装された機能 ※React16.6で実験的機能として追加されていた Suspense でできること データ取得中ローディング状態の宣言的な記述 コンポーネント単位でのSSR コンポーネント単位でのJSロード コンポーネント単位でのHydration Suspense は単にローディングを宣言的に記述できるだけの機能ではない Suspenseはローディングを宣言的に記述できるもの、といった内容を目にすることが多い印象です。 しかし、Suspenseは単にローディングを宣言的に記述できるだけ
React.ComponentPropsを使ったコンポーネントの Props 設計
はじめに 汎用的なElementレイヤーのコンポーネントを作るときの Props定義はこうした方がよいのではないか、という話です。 ※ここで言うElementレイヤーとは： input, button, label など、atomic design でいう atom の部分 ComponentPropsを使おう このように一つ一つのプロパティを定義するより type Props = { value?: string; onChange?: React.ChangeEventHandler<HTMLInputElement>; }; export const Input = ({ value, onChange }: Props) => ( <input value={value} onChange={onChange} /> );
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
