「いいね」ボタンは即座に反応し、ハートが塗りつぶされ、カウンターが増える——サーバーがまだ何一つ応答していないうちに。これはマイクロインタラクションの記事で扱った速さの錯覚よりも一歩踏み込んだものです。インターフェースがまだ存在しない状態を表示し、それがすぐに実現すると仮定しているのです。この仮定が外れたときに本当に嘘を撤回できる、安全な作り方を確認します。そして、手動の`setState`と`catch`が、`useOptimistic`が提供するものの劣化版でしかない理由も見ていきます。
ユーティリティクラス`.mt-4`は、論理的には後から追加された分勝つはずなのに、`.card .card__header .card__title`というルールに負けてしまいます。これは偶然ではなく、詳細度が設計通りの仕事をしているだけです。`@layer`は、詳細度と一緒にではなく、その手前で働くまったく新しい対立解決の軸を導入します——そして、ネット上のドキュメントの一部さえ誤って説明してしまうほど直感に反する落とし穴が一つあります。
「use server」は、APIルートへのfetch呼び出しに対する単なるシンタックスシュガーのように見えます。だからこそ、多くの実装はこれをただの関数呼び出しとして扱ってしまいます。これは具体的な代償を伴う誤解です。「use server」と記されたすべての関数は、ネットワーク上の公開エンドポイントになります。そして、この仕組みの上に作られたフォームは、JavaScriptが読み込まれる前から動作します。このディレクティブの裏側で実際に何が起きているのか、そしてドキュメントを一目見ただけでは分からない落とし穴がどこにあるのかを確認していきます。
フォームのフィールドは、中のinputが不正な値のとき赤くハイライトされるべきである。単純な話に思えるが、CSSは25年もの間、要素に対してその内側で何が起きているかを問い合わせる方法を持たず、その逆しかできなかった。:has()がこの方向をどう逆転させるのか、通常のコンビネータとどう違うのか、そしてこの新しい力が実際にパフォーマンス上のコストを伴う場面はどこかを見ていく。
同じ商品カードなのに、グリッドでは美しく見え、狭いサイドバーでは崩れてしまう——メディアクエリを注意深く選んでいたとしても。問題はコードにあるのではなく、メディアクエリがそもそも何を尋ねているかにある。画面の幅を尋ねているのであって、そのコンポーネントが実際に与えられたスペースを尋ねているわけではない。コンテナクエリがこの問いをどのように本来あるべき場所へ移し、要素が『クエリのコンテナ』になったとき実際に何が起きているのかを見ていく。
正しいHTMLはあくまで出発点にすぎない。アクセシビリティツリーの実際の仕組み、ARIAが思っている以上に害になるケース、そして実際に動くアコーディオン・ライブリージョン・Next.jsのフォーカス制御を一緒に作りながら見ていく。
