【テクニカル・上級編】Radix UIにおけるリストコンポーネントの設計思想 – HTML実践ガイド

Radix UIとセマンティックHTML：リスト構造の「極致」を実装する

多くのフロントエンドエンジニアが、`ul`や`li`を単なる「見た目のためのレイアウト要素」だと誤解している。しかし、Webのアクセシビリティを突き詰め、ブラウザのレンダリングパイプラインを深く理解しようとする我々にとって、リストは「意味論的なツリー構造」そのものだ。

特に、Radix UIのようなPrimitivesを用いた設計では、単にコンポーネントを配置するのではなく、ブラウザのアクセシビリティツリーをいかに美しく「彫刻」するかが、エンジニアとしての腕の見せ所になる。今回は、Radix UIの設計思想を借りつつ、プロダクション環境で確実に生き残るための「リスト構築術」を解剖する。

なぜRadix UIの設計思想を模倣すべきなのか

Radix UIの核心は、「DOMの構造と機能的役割を分離し、ARIA属性を極限まで抽象化する」ことにある。多くの開発者が独自のリストコンポーネントを作ろうとして陥る罠は、`role=”listbox”`や`aria-activedescendant`などの管理で自滅することだ。

セマンティックなリストを構築する際、我々が守るべき鉄則は以下の3点だ。

1. DOMのフラット化と論理構造の維持: 過度なネストはアクセシビリティツリーの走査コストを増大させる。
2. キーボードナビゲーションの非同期管理: ユーザーの操作とDOMの更新の間に「ミスマッチ」を起こさせない。
3. 型安全性によるガードレール: TypeScriptを使い、リストのデータ構造とレンダリング結果を静的に拘束する。

実践：高負荷に耐える「制御されたリスト」の実装

動的にアイテムが増減するリストを考える。ここで最も恐ろしいのは、Reactのレンダリングサイクルとブラウザのペイント処理が競合し、リフローが頻発することだ。

以下は、Radix UIの思想を取り入れた、堅牢なリストコンポーネントの雛形である。

import React, { useMemo, useRef } from ‘react’;

/

• 型安全性を確保するための定義
• リストアイテムのキー管理はパフォーマンスの肝。

/
interface ListItemProps {
id: string;
label: string;
}

export const SemanticList: React.FC<{ items: ListItemProps[] }> = ({ items }) => {
// レンダリング負荷を下げるために、リストの算出結果をメモ化
// 依存関係を最小限に絞り、不要な再計算を防ぐ
const memoizedList = useMemo(() => {
return items.map((item) => (

));
}, [items]);

return (

{memoizedList}

);
};

パフォーマンスの最適化：リフローとレイアウトシフトの回避

大規模なリスト（例えば1,000件以上のアイテム）を扱う際、`ul`の直下に大量の`li`を並べるのは愚策だ。ブラウザのレンダリングエンジンは、これら全ての要素に対してレイアウト計算を試みる。

1. 仮想スクロールとの併用

リストのDOMノードが肥大化しそうな場合は、迷わず仮想スクロール（Windowing）を導入せよ。Radix UIのPrimitivesと組み合わせる際、`aria-setsize`や`aria-posinset`を動的に制御しなければならない。これらを怠ると、スクリーンリーダーはリスト全体のサイズを正しく把握できず、ユーザー体験を著しく損なう。

2. 非同期競合のハンドリング

リストの更新がAPIのレスポンスに依存する場合、`useTransition`や`useDeferredValue`を活用して、UIのブロッキングを防ぐのが現代のスタンダードだ。

import { useDeferredValue } from ‘react’;

// リストの検索フィルタリングなどで使用
const deferredItems = useDeferredValue(items);

// フィルタリング処理中の不整合を防ぐため、
// 状態更新とレンダリングの優先順位をReactのスケジューラに委ねる

エッジケース：キーボード操作の「罠」

キーボードの矢印キーによる操作（`ArrowDown`, `ArrowUp`）を実装する際、多くのエンジニアは単なる`index`の管理に終始する。しかし、現実にはフォーカス可能な要素が非表示（`display: none`）になっていたり、DOMから一時的に削除されていたりするエッジケースがある。

Radix UIが提供する`Roving Focus`の考え方を参考に、以下のバグ回避を徹底してほしい。

• フォーカス管理の分離: DOMのレンダリング順序と、ユーザーが体験する論理順序を切り離す。
• ARIAライブリージョンの活用: 動的にリストの内容が更新された際、`aria-live=”polite”`を付与し、スクリーンリーダーに変化を適切に伝える。

結論：コードは「意味」を語るべきだ

Webアプリケーションのフロントエンドにおいて、HTMLは単なるタグの羅列ではない。それは情報の「階層」であり、ブラウザへの「指示書」だ。Radix UIのようなライブラリが示唆しているのは、単に実装を楽にすることではない。「ブラウザのネイティブな挙動を尊重しながら、いかにして複雑なアプリケーションの状態をセマンティックに表現するか」という思想である。

君たちが書く一行の `