Reactの歴史と設計思想の変遷：UI構築を再定義した10年

リサーチ
2025.10.03

はじめに

Reactは、2013年にFacebookによってUIライブラリとして公開された。Reactの進化は、APIの追加やパフォーマンスの向上といった技術的変化にとどまらず、UIとは何か、状態とは何か、責務はどこにあるべきかといった問いに対する再定義の連続であったとも言える。

ここでは、Reactの技術的変遷を時系列で整理しつつ、それぞれのフェーズにおいて提示された設計哲学の変化をまとめてみることにする。

宣言的UIとコンポーネント指向の誕生（2013–2015）

Reactの登場は、命令型UIの限界に対する批判的応答であった。jQueryに代表される命令型アプローチでは、状態とDOMの整合性が開発者の責任に委ねられ、複雑化するUIに対して脆弱であった。

Reactはこの問題に対し、「UIは状態の関数である」という設計原則を提示する。JSXによる宣言的記述は、UIの構造をコード上に明示し、Virtual DOMはこの設計原則をパフォーマンス低下の代償なしに実装した。さらに、UIを再利用可能なコンポーネントとして分割することで、構造と責務の単位化が進むことになった。

特徴命令型UI（例：jQuery）宣言型UI（例：React）
DOM操作明示的に記述自動的に差分更新
状態管理開発者が手動で同期状態に応じて再描画
可読性複雑化しやすい構造が明示的
図1：命令型UIと宣言型UIの比較

状態管理とデータフローの抽象化（2015–2018）

Reactの普及とともに、状態管理の複雑性が課題として顕在化した。Fluxアーキテクチャ、そしてそれを簡潔に再構成したライブラリであるReduxの登場は、状態の変更を明示的なActionとReducerによって管理し、単一の信頼できるソース（Single Source of Truth）に集約するという設計思想を提示した。状態の一元管理を徹底するというわけだ。

Reduxでは、アプリケーション全体の状態を一つのオブジェクトツリーとしてStoreに集約する。これが「単一の信頼できるソース」となり、アプリケーションの状態（State）は常にここを参照すればよいことになる。さらに、この状態を直接変更することはできず、変更には必ずActionと呼ばれるオブジェクトを発行しなくてはならない。そして、この状態変更はReducerと呼ばれる純粋関数によってのみ実行できる。

この時期のReactは、「UIの構造」から「UIの振る舞い」へと関心を拡張し、状態と副作用の分離によって、予測可能性とテスト可能性を高める方向へと進化した。

Next.jsの登場：フルスタック化への起点

2016年、VercelによってNext.jsが公開された。これは、Reactが「UIライブラリ」 から「フルスタックフレームワーク」へと進化する歴史的転換の起点となった。Nextが提示した設計は以下のようなものとなる。

まず、それまでのReactはルーティングを提供していなかったが、Next.jsは`pages/ディレクトリ` 構造がそのままURLになるという直感的な設計を導入した。

Nextは、ページごとにサーバーサイド・レンダリング（SSR）／静的サイト生成（SSG）を選択できる柔軟性を提供し、SEOの改善と初期パフォーマンスの向上をもたらした。

Nextについては、後段で詳しくまとめる。

Fiberアーキテクチャ：UIレンダリングの再構成とスケジューリング

ReactのFiberアーキテクチャ（2017年導入）は、従来の「再帰的な同期レンダリングモデル」の限界に対する根本的な再設計だった。従来のReactは、ツリー構造の再描画を一気に処理するため、複雑なUIや大量の更新がある場合に、ブラウザのメインスレッドを長時間占有してしまう問題があった。 Fiberはこの問題に対して、以下のような設計転換を提示した。

  • レンダリングを「割り込み可能な作業」にする
    Fiberは、UIの再描画を「単一の不可分な処理」ではなく、「分割可能な作業単位（unit of work）」として扱う。これにより、Reactはレンダリング処理を中断・再開できるようになり、ユーザー操作や高優先度のイベントに応答する余地を残す。
  • 優先度ベースのスケジューリング
    Fiberは、各更新に対して優先度を割り当て、重要な更新（例：入力フィールドの変更）を先に処理する。これは、Reactが「すべての状態変化は等価ではない」という立場を取ったことを意味する。
    UIの更新は、単なる状態反映ではなく、「ユーザー体験の設計対象」である
  • 再帰からループへの構造転換
    技術的には、Fiberは従来のスタックベースの再帰的なツリー探索処理を、ツリーの深さ優先探索リストとしてヒープ上に再実装することで、割り込みと再開を可能にした。これは、UIレンダリングを「関数の呼び出し」から「スケジュール可能なタスク」へと再定義する転換である。

Context APIの公式導入：Prop Drillingからの解放

一方で、Reactのコンポーネントツリーを深く辿ってデータを渡す「Prop Drilling」の問題は、Reduxを導入しない小〜中規模のアプリケーションにとって依然として負担だった。これに対し、React 16.3では、非推奨だった旧APIに代わる新しいContext APIが正式に導入された。これは、コンポーネントツリーの階層を無視して、認証ユーザーやテーマなどのグローバルなデータを効率的に共有するための標準機能である。Context APIは、Reduxのような厳格なデータフローは提供しないものの、「Prop Drillingの回避」という長年の課題をReactのコア機能として解決し、Reduxなどの外部ライブラリを使わずに状態管理を扱う軽量な道を開いた。特に、この後に導入されるHooksと組み合わせることで、Context APIはシンプルなアプリケーションにおける本格的な状態管理の基盤となる。

Context API 小〜中規模のアプリケーション、または更新頻度が低いグローバルなデータ
（テーマ、認証情報など）。
Redux (Toolkit)大規模なアプリケーション、
または管理すべき状態が多く複雑で、頻繁に更新されるデータ。

関数型への回帰とHooksの導入（2019–2021）

Hooksの登場は、Reactの設計哲学における大きな転換点であった。useStateやuseEffectなどの基本Hooksは、関数コンポーネント内で状態と副作用を管理することを可能にし、クラスベースの継承モデルからの脱却を促した。

この変化は、関数型プログラミングの影響を色濃く反映している。状態や副作用は関数のスコープ内に閉じられ、カスタムHooksによってロジックの抽象化と再利用性が向上した。

観点クラスコンポーネント関数コンポーネント（Hooks）
状態管理this.stateuseState
ライフサイクルcomponentDidMount等useEffect
再利用性継承中心カスタムHooksによる抽象化
図２：クラスコンポーネント vs 関数コンポーネント（Hooks使用）

非同期レンダリングと責務の再分割（2022）

Concurrent Features

Fiberアーキテクチャは、再帰的な更新処理を分割し、スケジューラによって制御可能にすることで、UIの応答性を優先する設計を可能にしたが、React 18において導入されたConcurrent Featuresは、UIレンダリングにおける即時性の原則を再考するものであった。

Suspense：非同期UIの構成と待機の設計

Suspenseは、Reactにおける「非同期処理のUI統合」を担う設計機構である。従来、非同期処理（データ取得、コード分割など）は、UIとは別の責務として扱われていたが、SuspenseはこれをUI構築の一部として再定義する。

  • 「待機」はUIの構成要素であるSuspenseは、非同期処理の完了を待つ間に表示するUI（fallback）を定義することで、「待機状態」をUIの一部として設計可能にする。これは、UX設計において「待ち時間を設計する」という転換である。待機は副作用ではなく、UIの状態である
  • Streamingとの親和性
    React 18以降、SuspenseはStreaming SSRと組み合わせることで、部分的なUIを先に表示し、遅延部分を後から補完する設計が可能になった。これは、UIは完成してから表示するのではなく、段階的に構成される方がコントロールしやすい、という発想に基づいている。
  • Suspenseの抽象性と汎用性
    Suspenseは、データ取得、コード分割、画像読み込みなど、あらゆる非同期処理に適用可能な抽象的設計機構である。これは、Reactが非同期性をUI設計の重要な要素、と位置づけ直したたことを意味する。

useTransition：更新の優先度制御と応答性の設計

useTransitionは、Concurrent Featuresにおけるもう一つの中核的機構であり、Suspenseが「待機状態のUI化」を担うのに対し、useTransitionは「更新の優先度付け」を担う。これは、UIレンダリングにおいて「すべての更新が等しく緊急ではない」という認識に基づいている。

  • 緊急性による更新の分類 useTransitionは、startTransitionAPIを通じて、状態更新を「緊急(urgent)」と「遷移(transition)」に分類する。ユーザー入力やアニメーションなど即座に反映すべき更新は緊急として扱われ、検索結果の表示や重い計算結果の反映など遅延可能な更新は遷移として扱われる。これにより、Reactは緊急な更新を優先し、重い更新処理中でもUIの応答性を維持できる。
  • 中断可能な更新 遷移としてマークされた更新は、より優先度の高い更新が発生した際に中断され、後回しにされる。これは、Fiberアーキテクチャの「作業の分割と中断」という特性を活用したものであり、「一度開始した処理は完了まで止められない」という従来の制約からの解放である。
  • isPendingによる待機状態の明示化 useTransitionが返すisPendingフラグは、遷移中の状態をUIとして表現可能にする。これは、Suspenseのfallbackと同様に、「処理中であることを隠すよりもUIとして設計する」という考え方の表れである。ローディングスピナーではなく、既存のUIを表示しつつ透明度を下げるなど、より洗練されたUX設計が可能になる。
  • Suspenseとの協調動作 useTransitionとSuspenseは相補的に機能する。startTransition内で発生したSuspenseは、既存のUIを保持したまま新しいコンテンツの準備を進める。これにより、「画面全体が突然ローディング状態になる」のではなく、「現在のコンテンツを表示しながら次のコンテンツを準備する」という、より自然なUX遷移が実現される。

結果として、SuspenseとuseTransitionは、非同期処理とUI描画の統合を促進し、ユーザー体験の滑らかさを設計の中心に据えることを可能にした。Suspenseが「待機をUIの一部として設計する」ことを可能にし、useTransitionが「更新の重要度を設計の要素とする」ことを可能にすることで、Reactは「時間軸を含めたUI設計」という新たな設計空間を開いたのである。

React Server Components（RSC）

React Server Components（RSC）は、Reactの設計における「責務の分離」と「実行環境の再構成」に対する最も根本的な再定義となる。RSCは、UIの責務をクライアントからサーバへと再分割する新たなレンダリングのアプローチである。コンポーネントの実行は原則としてサーバー側となるが、従来のSSRやCSRとは異なって、RSCではサーバーサイドとクライアントサイドの分担に対して、より粒度の細かい制御を可能にする。

RSCはReactチームによって2020年に提案され、Next.jsのApp Routerにおいて本格的に実装されたが、その特徴は以下のようにまとめられる。

クライアント中心から責務分割へ

従来のSPA（Single Page Application）モデルでは、UIの構築・状態管理・データ取得などの責務がすべてクライアントに集約されていた。これは、初期表示の遅延、バンドルサイズの肥大化、セキュリティ上の懸念などを引き起こしていた。RSCはこの問題に対して、以下のような転換を行う：

  • UIの構築責務をサーバ側に移すことで、クライアントへのJS送信を最小化
  • データ取得とUI構成をサーバ側で統合し、クライアントは表示とインタラクションに専念
  • React 18のStreamingとSuspenseを活用し、部分的なUIを段階的に構成

境界の明示と責務の宣言的設計

RSCの設計思想では、UIを「サーバー側で構築する部分」と「クライアントで実行する部分」に分割できるようにすることが重要視されている。その境界を宣言的に示す仕組みとして、フレームワークごとに異なる実装が存在する。
たとえば Next.js の App Router では、特に指定がない場合コンポーネントはサーバーコンポーネントとして扱われ、ファイルの先頭に 'use client' を記述することで、そのモジュールと依存ツリーをクライアントコンポーネントとして明示できる。
このように、「境界を宣言的に示す」という考え方は React 側の設計原則であり、「デフォルトはサーバー扱い」という具体的な挙動が Next.js においても実装上の方針となる。

  • 実行環境の責務をコード上に明示することで、設計の透明性と可搬性が向上
  • サーバ側での処理（データ取得、認証、ロジック）とクライアント側の処理（インタラクション、アニメーション）を分離可能に
  • UI構築が「構造と状態」だけでなく「実行環境と責務」によって定義される
    RSCは、Reactの宣言的UI設計を「実行環境の宣言的設計」へと拡張する

実装上の留意点と設計的含意

RSCは強力な設計機構である一方、以下のような制約と設計責任を伴うことになった。

  • サーバ側では`useEffect`などのクライアント専用フックは使用不可
  • サーバーコンポーネントは関数型的な実装が求められる。具体的には、サーバーコンポーネントはインターフェイスレベルで参照透過性を保ち、 同じpropsに対して予測可能なUIを返すべきであり、 データ取得などの副作用は実装の内部に隠蔽される。
  • クライアントとの境界設計が明示的になるため、設計者の理解と責任が問われる

RSCとReactの設計原則の連続性

RSCは、Reactの設計における以下の原則を継承・拡張している：

Reactの原則従来の実現方法RSCによる拡張
UIは状態の関数useState, useEffectサーバ側データ取得をコンポーネントレベルで統合
宣言的構造JSXによるUI構築実行環境の責務もJSXで宣言可能に
再利用性コンポーネント分割サーバ/クライアント両環境で再利用可能な設計へ
非同期性Suspense, useTransitionサーバ側非同期処理との統合とStreaming

RSCは、UI設計における「どこで構築すべきか」「誰が責任を持つべきか」という問いに対する継続的な応答と捉えることができる。それは、Reactが「UIは状態の関数である」という原則から出発し、「UIは実行環境に応じて分割可能な関数である」という新たな視点に至ったと考えられる。

RSCは、Reactの進化の中でも最も本質的な転換点であると言え、今後のUI設計における責務分割・実行環境設計・宣言的構成のあり方を再定義する可能性を秘めている。

React 19：非同期UIとサーバ責務の統合的再設計（2024–）

React 19は、Reactの設計思想における「責務の分離」と「UI状態の管理」に対して、より統合的かつ宣言的なアプローチを提示する重要なマイルストーンである。従来のReact 18までの設計では、非同期処理やフォーム送信、エラーハンドリングなどは複数のフックを組み合わせて手動で管理する必要があった。

React 19では、これらの責務を統合的に扱うための新しい概念「Actions」が導入された。

Actions：非同期処理の設計単位化

Actionsは、非同期関数をトランジションの中で扱うことで、pending状態、エラー処理、楽観的更新（optimistic update）などを自動的に管理する仕組みである。これにより、UIの応答性を保ちつつ、状態更新の設計が簡素化された。これは状態管理と副作用処理を一つの設計単位（Action）に統合するものである。

新しいフック群による状態管理の抽象化

React 19では、Actionsを支える以下の新しいフックが導入された：

  • useActionState：非同期処理に伴う状態（pending, errorなど）を一元管理
  • useFormStatus：フォーム内の状態をコンポーネント間で共有可能に
  • useOptimistic：楽観的UI更新をワンライナーで実装可能に

これらのフックは、UIの状態とユーザー体験をより密接に結びつける設計を可能にする。

React Server Componentsとの統合強化

React 19では、RSC（React Server Components）との連携も強化されている。Actionsはサーバー側でも定義可能であり、フォーム送信やデータ更新などの処理をサーバーコンポーネント内で完結させることが可能になった。これは、サーバーアクションとクライアントUIの協調という視点をもたらした。

その他の改善点

  • forwardRefが非推奨の方向へ：refの受け渡しがより直感的に。
    （forwardRefは互換性のため存続するが、将来的に非推奨に。）
  • 自動バッチングの拡張：より多くのシナリオで効率的な再レンダリングが可能に
  • React Compilerとの統合：コードの自動最適化とパフォーマンス向上

このように、React 19は「非同期UI」「状態管理」「サーバ責務」の3領域において、設計の統合と抽象化を推し進めたバージョンであり、Reactの進化の延長線上に位置づけられる。

領域技術設計思想
非同期処理Actions, useActionState状態と副作用の統合管理
UI応答性useOptimistic, useTransition楽観的更新とUX最適化
サーバ責務RSC, サーバーActionsクライアント/サーバの責務分割
図４：React 19の設計思想マップ

Next.js サイドから見た発展

多少の重複があるが、ここで改めて、Next.jsの側から進化の歴史を時系列に沿って整理してみる。ReactとNextがその設計において補完関係にあることは言うまでもない。

Next.jsが初めて登場したのは2016年である。当時、ReactによるWebアプリケーション開発は主にクライアントサイド・レンダリング（CSR）を前提としており、SEOや初期表示速度に課題を抱えていた。当時のReactはUIライブラリとしての純粋性を保ち、ルーティングやデータ取得、レンダリング戦略といったアプリケーション構成には関心を示さないという方針をとっているように見えた。しかしながら、実際のWebアプリケーション開発においては、ルーティング、データ取得、レンダリング戦略、さらにはサーバーとの統合といった構成上の課題が常に存在する。

このような状況下で、Zeit（現Vercel）によって開発されたNext.jsは、Reactの設計における空白を埋める実装例として登場した。

初期バージョン（v1〜v8）

初期バージョンにおいては、ファイルベース・ルーティング、自動コード分割、そして特にサーバーサイド・レンダリング（SSR）の簡易化を特徴とし、Reactの宣言的UIを実用レベルのWebアプリケーションへと昇華させる役割を果たしたと言えそうだ。これは、Reactの「UI中心主義」に対して、Next.jsが「構成と実行環境への関心」を付加することで補完関係を築いた初期事例である。

転換期：モダンWeb開発の構造化（v9〜v12）

Next.jsはその後も、開発者体験（DX）とアプリケーション性能の両立を目指して進化を続けた。

  • v9（2019年）では、API Routes（pages/api）の導入により、サーバーサイドロジックをNext.jsプロジェクト内に統合可能となった。これは、Reactに対して、Next.jsが「UIとロジックの統合」を志向することで、フルスタック・フレームワークへの転換点を示したものである。また、ダイナミック・ルーティングの導入やAutomatic Static Optimizationの改良は、Reactの宣言的UIに対して「宣言的な構成と最適化」を付加する試みであった。
  • v10〜v11（2020〜2021年）では、next/imageによる画像最適化やi18n対応、Webpack 5の採用など、開発体験と国際化対応が強化された。これらは、Reactの「コンポーネント中心主義」を維持しつつ、Next.jsが「運用上の課題に対する応答」を示した例である。
  • v12（2021年後半）では、Rust製コンパイラSWCの導入により、ビルド速度と開発効率が劇的に向上した。さらに、Edge Middlewareの登場により、グローバルなロジック処理が可能となった。これは、Reactの「クライアント中心の設計」に対して、Next.jsが「エッジ環境を含む実行モデルの拡張」を提示したものである。

App Routerとサーバー・コンポーネントの時代（v13以降）

Next.jsの設計における進化において、最も重要な転換点はv13（2022年）におけるApp Routerの導入である。これは、React本体が提唱するReact Server Components（RSC）をNext.jsが先行実装したものであり、コンポーネント単位でのサーバー・クライアント分離を可能にした。

App Routerは、従来のPages Routerとは異なり、UIとデータ取得、レンダリング戦略をコンポーネントレベルで制御可能とする新しいアーキテクチャである。これは、Reactの「宣言的UIと状態管理の分離」という考え方を、Next.jsが「宣言的なレンダリング責務の分離」へと拡張した実装例である。

  • v13（2022年10月）App Router（ベータ版）発表。Pages Routerの後継として、RSCを基盤とする新しいルーティングシステムとして導入された。Pages Routerとは共存可能で段階的な移行が始まった。
    クライアントで動く、という前提が崩れ、「’use client’をどこに書くべきか」などサーバー／クライアント境界の概念を理解することが学習コストを高くすることになった。さらには、一部の人気ライブラリとの互換性問題などが発生して混乱が発生した。
  • v13.4（2023年5月）App Routerが安定版に昇格し、新規プロジェクトのデフォルトになった。機能と安定性が大きく向上し、公式に本番利用が推奨される。安定版になったことで、新規プロジェクトでのApp Router採用が本格化。コアな機能（ネストされたレイアウト、データ取得など）が信頼性を増す。
  • v14（2023年10月）では、App Routerが安定版となり、Partial Pre-Rendering（PPR）やServer Actionsのプレビューが導入された。これにより、静的・動的レンダリングのハイブリッド化と、API Routesを介さないサーバー処理の統合が可能となった。これは、Reactの「UIとロジックの分離」に対して、Next.jsが「UIとロジックの再統合」を志向する転換を示している。
    （PPRは、静的・動的コンテンツを同一ページ内に混在させる技術）
  • v15（2024年）では、Server Actionsが正式に安定版として登場し、React 19との連携によってフォーム処理やサーバーサイドロジックの記述が劇的にシンプルかつ安全になった。Next.jsは「究極のフルスタック・フレームワーク」としての完成度を高めている。フォーム処理やデータ操作がReactコンポーネント内で直接記述可能となることで、Reactの「コンポーネント中心主義」が「アプリケーション中心主義」へと拡張される可能性を示唆している。

周辺技術：Reactの設計原則を支える外縁

状態管理：責務の分離と可観測性の設計

Reactは「UIは状態の関数である」という原則を掲げるが、状態の所在と変化の管理はライブラリ外部に委ねられてきた。ReduxやRecoilはこの空白を埋めるために登場した。

  • Reduxは、状態を「単一の確かなソース（Single Source of Truth）」に集約し、Action→Reducer→Storeという明示的な流れを設計した。これは、Reactの「宣言的UI」と整合する「宣言的状態遷移」の発想である。
  • Recoilは、状態を「粒度の細かいAtom」に分割し、依存関係を自動で追跡する。これは、Reactのコンポーネント設計と親和性が高く、「状態もUIの構成要素である」という立場を補完する。

状態管理ライブラリは、Reactの「UIは状態の関数である」という原則を、より精緻な設計単位へと展開する補助線である

ビルドツール：構文と実行環境の抽象化

ReactはJSXという構文を導入することで、UI構築をコード上に明示した。しかしJSXはブラウザが直接解釈できるものではなく、トランスパイルが必要である以上、ビルドツールはフレームワークの一部として必須となる。

  • Webpackは、モジュール依存関係の解決とバンドルを担い、Reactの「構造的UI設計」を実行可能な形に変換する。
  • Viteは、ESMベースの高速ビルドを実現し、Reactの「即時フィードバックによる設計改善」という開発体験を支える。

ビルドツールは、Reactの「宣言的構文」を「実行可能なUI」に変換する架橋であると言える。

UI設計：構造とスタイルの責務分離

ReactはUIをコンポーネントとして構造化するが、スタイルの設計責務は明示的に定義されていない。ここに、Tailwind CSSやMUIといったUI設計ツールが補完的な役割を果たす。

  • Tailwind CSSは、Atomic CSSに基づき、スタイルをユーティリティクラスとして分割する。これは、Reactの「構造と責務の単位化」と整合し、「スタイルもUIの一部として宣言的に扱う」設計を可能にする。
  • MUI（Material UI）は、Googleのデザイン原則に基づくコンポーネント群を提供し、Reactの「再利用可能なUI構成」を視覚的・操作的に具現化する。

UI設計ツールは、Reactの「構造的UI設計」を「視覚的・操作的UI設計」へと拡張する媒介である。

Tailwind CSS：スタイル設計の責務分離と宣言性の拡張

Reactは、UIを構造的・責務的に分割するコンポーネント指向を採用してきたが、スタイルの設計責務については明示的な指針を持たない。これは、CSS-in-JSやCSS Modulesなど多様なアプローチが併存する背景でもある。

Tailwind CSSは、この空白に対しての応答を提示した。ユーティリティファーストの設計原則に基づき、スタイルを粒度の細かいクラス群（Atomic CSS）として定義し、HTML（JSX）上に直接記述することで、スタイルの責務を構造と統合する。

設計思想の接点

  • 宣言性の拡張：Reactが「UIは状態の関数である」と定義したのに対し、Tailwindは「スタイルは構造の属性である」と位置づける。両者は、UIの構造と振る舞いをコード上に明示するという点で共鳴する。
  • 責務の分離と統合：Tailwindは、スタイルの定義をCSSファイルからJSX構造内に移すことで、設計責務をコンポーネント単位に集約する。これは、Reactの「構造と責務の単位化」という原則を視覚的設計にまで拡張する試みである。
  • 再利用性と可搬性：Atomic CSSは、スタイルの粒度を最小化することで、UI構成要素の再利用性を高める。これは、Reactのコンポーネント再利用指向と整合的である。

Tailwind CSSは、Reactの「構造的UI設計」に対して「視覚的責務の宣言的設計」という補完を提供する。CSS-in-JSが「スタイルをロジックに閉じ込める」アプローチであるのに対し、Tailwindは「スタイルを構造に統合する」立場を取る。これは、UI設計における可読性・可搬性・責務の明示性を重視するReactの設計哲学と深く接続している。

技術領域主なツール設計思上のの接点
状態管理Redux, RecoilUIとロジックの責務分離
ビルドWebpack, ViteJSX/TSXの構文最適化
SSR/SSGNext.js, Gatsby実行環境の選択と責務分割
UI設計Tailwind CSSAtomic CSSによる宣言的スタイル設計
図3：Reactと周辺技術

設計思想の前進としてのReact

Reactの歴史は、UIライブラリの進化というよりも、「UI設計とは何か」という問いへの設計的応答の連続であった。宣言的UI、状態管理、関数型、非同期レンダリング、サーバ統合——それぞれのフェーズにおいて、ReactはUIの責務と構造を再定義してきた。

Reactを使うということは、単にAPIを呼び出すことではなく、UI設計に対する立場を選ぶことである。技術者としてReactを理解するならば、その設計思想の転換・変遷を追うことは非常に重要であると思われる。

参考文献

英語

  1. React Official Documentation – https://react.dev
  2. Dan Abramov, “Redux: A predictable state container for JavaScript apps” – https://redux.js.org
  3. React Server Components RFC – https://github.com/reactjs/rfcs/pull/188
  4. Next.js Documentation – https://nextjs.org/docs
  5. Tailwind CSS Documentation – https://tailwindcss.com
  6. Fiber Architecture Overview – https://github.com/facebook/react/blob/main/packages/react-reconciler/src/ReactFiberWorkLoop.new.js
  1. Sebastian Markbåge, “The Future of React” (JSConf EU 2019) – https://www.youtube.com/watch?v=ByBPyMBTzM8

日本語

  1. React v19公式ブログ
  2. Qiita: React 19の変更点と例

コメント

タイトルとURLをコピーしました