React Server ComponentsにおけるCSS

Wed, 25 Mar 2026 00:00:01 GMT

2023年5月4日、VercelはNext 13.4の安定版リリースを発表し、React Server Componentsを基盤として構築された初のReactフレームワークとなりました。

これは非常に大きな出来事です！RSC（React Server Components）は、Reactにおいてサーバー専用のコードを記述するための公式な方法を提供してくれます。私のブログ記事「Making Sense of RSC（RSCを理解する）」でも書いたように、RSCは多くの興味深い新たな扉を開いてくれます。

しかし、オムレツを作るには卵を割らなければなりません。 RSCはReactの仕組みに対する根本的な変更です。その影響で、私たちが使ってきたライブラリやツールの一部は…スクランブルエッグのようにごちゃ混ぜになってしまいました 😅。styled-componentsやEmotionのようなライブラリを使用している私たちにとって、今後の明確な道筋は存在していませんでした。

過去数ヶ月間、私はこの問題について深く掘り下げ、互換性の問題についての理解を深め、どのような選択肢があるのかを学んできました。現時点で、私は状況全体をかなりしっかりと把握できていると感じています。

また、水面下で進んでいた非常にエキサイティングな動向もいくつか発見しました。 ✨

CSS-in-JSライブラリを使用しているなら、この記事が多くの疑問を解消し、今後の具体的な選択肢を提示する手助けになれば幸いです。

ただ____を使えばいい。

ネット上でこの議論が持ち上がると、最もよくある提案の1つは、別のCSSツールに切り替えることです。結局のところ、Reactエコシステムには選択肢が山ほどあるのですから！

しかし、私たちの多くにとって、これは現実的な提案ではありません。私は自分のブログとコースプラットフォーム全体で、5,000以上のstyled-componentを使用しています。まったく別のツールへ移行するというのは、口で言うほど簡単なことではありません。

LLM（大規模言語モデル）の登場により、この種の大規模なリファクタリングは潜在的には実行可能になりますが、それでも多くの手作業による検証が必要になるでしょう。そして正直なところ、たとえ指を鳴らすだけで即座に別のライブラリに切り替えることができたとしても、私はそうしたくありません。私はstyled APIが本当に好きなのです！

このブログ記事の後半では、いくつかの代替CSSライブラリについて説明しますが、ここではstyled-componentsに似たAPIを持つ選択肢に焦点を当てます。

2026年のアップデート：styled-componentsが復活しました！

2026年1月、styled-componentsチームはv6.3.0を公開し、React Server Componentsのサポートを導入しました！ 🎉

これは正直言って私にとって非常にエキサイティングなことです。昨年、styled-componentsが最小限の体制（人員）で「メンテナンスモード」に入ったとき、私はライブラリに大きなアップデートはないだろうと思い込んでいましたが、それは間違っていました！つい先週、リードメンテナーのEvan Jacobs氏が、このライブラリが現在も活発にメンテナンスされていることを明言しました（別タブで開きます）。

React Server Componentsのコンテキストでstyled-componentsを使用する方法については、こちらで学べます：

styled-components ドキュメント：React Server Components（別タブで開きます）

React Server Componentsを紐解く

互換性の問題を理解するためには、React Server Componentsについて理解する必要があります。しかし、その話をする前に、サーバーサイドレンダリング（SSR）について理解しているか確認する必要があります。

SSRは、いくつかの異なる戦略や実装を含む総称ですが、最も典型的なバージョンは次のようになります：

ユーザーが私たちのウェブアプリにアクセスする。
リクエストはNode.js（ブラウザを持たないサーバーランタイム）によって受信され、そこでReactが実行される。アプリケーションがレンダリングされ、初期UIのすべてを含む完全に形成されたHTMLドキュメントが生成される。
このHTMLドキュメントがユーザーのデバイスに読み込まれると、Reactはまったく同じコンポーネントをすべて再レンダリングし、サーバーで行われた作業を繰り返す。ただし、新しいHTML要素を生成するのではなく、サーバーによって生成された既存のHTML要素を「引き継ぐ（adopt）」(*)。これはハイドレーション（hydration）として知られている。

*ここでは「HTML要素」という用語を使用していますが、より正確な用語は「DOMノード」です。サーバーがHTMLを生成し、ブラウザがそれをDOMとして知られる動的な表現にレンダリングします。

Reactは、対話性（インタラクティビティ）を処理するためにユーザーのデバイス上で実行される必要があります。サーバーによって生成されたHTMLは完全に静的です。そこには私たちが記述したイベントハンドラ（例：onClick）は含まれず、私たちが指定した参照（ref属性による）もキャプチャされていません。

ではなぜ、まったく同じ作業をすべてやり直さなければならないのでしょうか？ Reactがユーザーのデバイスで起動したとき、既存のUIの集まりを発見します。しかし、どのコンポーネントがどのHTML要素を所有しているかといったコンテキスト（文脈）は一切持っていません。Reactは、コンポーネントツリーを再構築するためにまったく同じ作業をする必要があります。これにより、既存のHTMLを正しく結びつけ、イベントハンドラや参照を正しい要素にアタッチできるようになります。

Reactは、サーバーの処理が終わった時点からスムーズに引き継げるよう、内部でコンポーネントツリーの対応関係（マップ）を構築する必要があるのです。

このモデルには大きな制限が1つあります。 私たちが書くコードはすべて、サーバーとクライアントの両方で実行されます。サーバー上でのみ排他的にレンダリングされるコンポーネントを作成する方法はありません。

データベースにデータを持つ、フルスタックのウェブアプリケーションを構築していると仮定しましょう。もしあなたがPHPなどの言語の経験者であれば、次のような書き方ができると期待するかもしれません：

function Home() {
  const data = db.query('SELECT * FROM SNEAKERS');

  return (
    <main>
      {data.map(item => (
        <Sneaker key={item.id} item={item} />
      ))}
    </main>
  );
}

理論的には、このコードはサーバー上で問題なく動作する可能性がありますが、そのまったく同じコードがユーザーのデバイス上で再実行されます。クライアント側のReactは私たちのデータベースにアクセスできないため、これは問題となります。Reactに対して「このコードはサーバー上でのみ実行し、結果のデータをクライアントで再利用してくれ」と伝える方法はありません。

Reactの上に構築されたメタフレームワークは、独自の解決策を考え出しました。例えば、Next.jsでは次のようなことができます：

export async function getServerSideProps() {
  const data = await db.query('SELECT * FROM SNEAKERS');

  return {
    props: {
      data,
    },
  };
}

function Home({ data }) {
  return (
    <main>
      {data.map(item => (
        <Sneaker key={item.id} item={item} />
      ))}
    </main>
  );
}

Next.jsチームはこう言いました。「よし、まったく同じReactのコードがサーバーとクライアントで実行されなければならないことは分かった…しかし、Reactの外部に、サーバー上でのみ実行される追加のコードを加えることができるぞ！」。

Next.jsサーバーがリクエストを受信すると、まずgetServerSideProps関数を呼び出し、そこから返された値はすべて、propsとしてReactコードに渡されます。まったく同じReactコードがサーバーとクライアントで実行されるため、問題はありません。なかなか賢いやり方ですよね？

私は正直、今日でもこのアプローチの大ファンです。しかし、Reactの制限による必要性から作成されたAPIであり、少し回避策のように感じられることも事実です。

また、各ルートの最上部にあるページレベルでしか機能しません。好きな場所にgetServerSideProps関数を自由に配置できるわけではないのです。

React Server Componentsは、この問題に対してより直感的な解決策を提供します。 RSCを使用すると、データベース呼び出しなどサーバー専用の作業をReactコンポーネント内で直接行えます：

async function Home() {
  const data = await db.query('SELECT * FROM SNEAKERS');

  return (
    <main>
      {data.map(item => (
        <Sneaker key={item.id} item={item} />
      ))}
    </main>
  );
}

「React Server Components」のパラダイムでは、コンポーネントはデフォルトでServer Components（サーバーコンポーネント）になります。サーバーコンポーネントはサーバー上でのみ実行されます。このコードはユーザーのデバイスでは再実行されません。コードはJavaScriptバンドルに含まれることすらありません！

この新しいパラダイムにはClient Components（クライアントコンポーネント）も含まれています。クライアントコンポーネントは、サーバーとクライアントの両方で実行されるコンポーネントです。あなたが「従来の」（RSC以前の）Reactで書いてきたすべてのReactコンポーネントは、クライアントコンポーネントです。つまり、既存の概念に新しい名前がついただけなのです。

ファイルの先頭に新しい"use client"ディレクティブを記述することで、明示的にクライアントコンポーネントとして指定（オプトイン）します：

'use client';

function Counter() {
  const [count, setCount] = React.useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

このディレクティブは「クライアント境界（client boundary）」を作成します。このファイル内のすべてのコンポーネントとインポートされたコンポーネントは、クライアントコンポーネントとしてレンダリングされます。最初にサーバーで、次にクライアントで再び実行されます。

他のReact機能（例：フック）とは異なり、React Server Componentsはバンドラーとの深い統合を必要とします。私がこれを書いている2024年4月現在、React Server Componentsを使用する唯一の現実的な方法はNext.jsを使うことです。ただし、将来的にはこれも変わると予想しています。

サーバーコンポーネントには制限がある

サーバーコンポーネントについて理解しておくべき重要な点は、これらが「完全な」React体験を提供するわけではないということです。ほとんどのReact APIはサーバーコンポーネントでは機能しません。

例えば、useStateです。状態（state）変数が変更されると、コンポーネントは再レンダリングされますが、サーバーコンポーネントは再レンダリングできません。そのコードは決してブラウザに送信されないため、Reactは状態の変更をどのように処理すればよいか全く分かりません。Reactの観点から見ると、サーバーコンポーネントによって生成されたマークアップは確定しており、クライアントで変更できません(*)。

*誤解のないように言っておくと、DOM自体が不変なわけではありません。プレーンなJavaScriptを使用して変更は可能です。しかし、Reactはサーバーコンポーネントによって生成されたアプリケーションの部分を再レンダリングはできません。

同様に、サーバーコンポーネント内でuseEffectを使用できません。エフェクトはサーバー上で実行されず、クライアントでのレンダリング後にのみ実行されるからです。そして、サーバーコンポーネントはJavaScriptバンドルから除外されるため、クライアント側のReactは私たちがuseEffectフックを記述したことを知る由もありません。

useContextフックでさえ、サーバーコンポーネントの内部では使用できません。なぜなら、Reactコンテキストをサーバーコンポーネントとクライアントコンポーネントの両方でどのように共有するかという問題を、Reactチームがまだ解決していないからです。

私はこのように考えています： サーバーコンポーネントは、少なくとも私たちが従来理解してきたような意味において、本当のReactコンポーネントではありません。オリジナルのHTMLを作成するためにサーバーによってレンダリングされる、PHPテンプレートにずっと近いものです。本当の革新は、サーバーコンポーネントとクライアントコンポーネントが同じアプリケーション内に共存できることなのです！

さらに深く掘り下げる

このブログ記事では、React Server Componentsの最も関連性の高い詳細、つまりCSS-in-JSフレームワークとの互換性の問題を理解するために知っておくべきことに焦点を当てます。

しかし、もしReact Server Componentsについてもっと詳しく学びたいのであれば、この新しい世界をより深く探求した別のブログ記事があります：

「Making Sense of React Server Components（React Server Componentsを理解する）」

CSS-in-JSライブラリの仕組み

さて、React Server Componentsの基本についてカバーしました。次に、💅 styled-componentsのようなCSS-in-JSライブラリの基本について話しましょう！

簡単な例を挙げます：

import styled from 'styled-components';

export default function Homepage() {
  return (
    <BigRedButton>
      Click me!
    </BigRedButton>
  );
}

const BigRedButton = styled.button`
  font-size: 2rem;
  color: red;
`;

.red-btnのようなクラスにCSSを記述する代わりに、新しく生成されたReactコンポーネントにそのCSSをアタッチします。これがstyled-componentsを特別なものにしている理由です。クラスではなく、コンポーネントが再利用可能なプリミティブ（基本要素）なのです。

styled.buttonは、新しいReactコンポーネントを動的に生成してくれる関数であり、そのコンポーネントをBigRedButtonという変数に割り当てています。その後、他のReactコンポーネントを使用するのと同じ方法で、このReactコンポーネントを使用できます。これにより、大きな赤いテキストを持つ

POSTD | ニジボックスが運営するエンジニアに向けたキュレーションメディア

React Server ComponentsにおけるCSS

React Server Componentsを紐解く

サーバーコンポーネントには制限がある

CSS-in-JSライブラリの仕組み