ゼロからReactアプリを構築する
既存のフレームワークでは要件が十分に満たせない場合、独自のフレームワークを構築したい場合、または単にReactアプリの基本を学びたい場合は、ゼロからReactアプリを構築することができます。
ステップ1: ビルドツールをインストールする
最初のステップは、vite、parcel、またはrsbuildのようなビルドツールをインストールすることです。これらのビルドツールは、ソースコードをパッケージ化して実行する機能、ローカル開発用の開発サーバー、およびアプリを本番サーバーにデプロイするためのビルドコマンドを提供します。
Vite
Viteは、モダンなWebプロジェクトに対して、より高速で軽量な開発体験を提供することを目指すビルドツールです。
npm create vite@latest my-app -- --template react-tsViteはオピニオンが強く、すぐに使える適切なデフォルト設定が付属しています。Viteには、高速リフレッシュ、JSX、Babel/SWC、およびその他の一般的な機能をサポートする豊富なプラグインエコシステムがあります。開始するには、ViteのReactプラグインまたはReact SWCプラグインおよびReact SSRサンプルプロジェクトを参照してください。
Viteは、すでに私たちの推奨フレームワークの1つであるReact Routerでビルドツールとして使用されています。
Parcel
Parcelは、すぐに使える優れた開発体験と、プロジェクトを開始から大規模な本番アプリケーションまで拡張できるスケーラブルなアーキテクチャを組み合わせています。
npm install --save-dev parcelParcelは、高速リフレッシュ、JSX、TypeScript、Flow、およびスタイリングをすぐに使える状態でサポートしています。開始するには、ParcelのReactレシピを参照してください。
Rsbuild
Rsbuildは、Rspackを基盤としたビルドツールで、Reactアプリケーションにシームレスな開発体験を提供します。慎重に調整されたデフォルト設定と、すぐに使用できるパフォーマンス最適化が付属しています。
npx create-rsbuild --template reactRsbuildには、高速リフレッシュ、JSX、TypeScript、スタイリングなどのReact機能のサポートが組み込まれています。開始するには、RsbuildのReactガイドを参照してください。
注記
React Native用のMetro
React Nativeをゼロから始める場合は、React Native用のJavaScriptバンドラーであるMetroを使用する必要があります。MetroはiOSやAndroidなどのプラットフォーム向けのバンドリングをサポートしていますが、ここで紹介するツールと比較すると多くの機能が不足しています。プロジェクトがReact Nativeのサポートを必要としない限り、Vite、Parcel、またはRsbuildから始めることをお勧めします。
ステップ2: 一般的なアプリケーションパターンを構築する
上記のビルドツールは、クライアントのみのシングルページアプリケーション（SPA）から始まりますが、ルーティング、データフェッチング、スタイリングなどの一般的な機能に対するさらなるソリューションは含まれていません。
Reactエコシステムには、これらの問題に対する多くのツールが含まれています。広く使用されているいくつかのツールを出発点としてリストしましたが、あなたにとってより適した他のツールを自由に選択してください。
ルーティング
ルーティングは、ユーザーが特定のURLにアクセスしたときに表示するコンテンツやページを決定します。URLをアプリの異なる部分にマッピングするためにルーターを設定する必要があります。また、ネストされたルート、ルートパラメータ、クエリパラメータも処理する必要があります。ルーターはコード内で設定することも、コンポーネントのフォルダとファイル構造に基づいて定義することもできます。
ルーターはモダンなアプリケーションのコア部分であり、通常、データフェッチング（ページ全体のデータを事前にフェッチして読み込みを高速化するため）、コード分割（クライアントバンドルサイズを最小化するため）、およびページレンダリングアプローチ（各ページの生成方法を決定するため）と統合されています。
以下の使用をお勧めします：
データフェッチ
サーバーや他のデータソースからデータを取得することは、ほとんどのアプリケーションの重要な部分です。これを適切に行うには、ローディング状態、エラー状態の処理、および取得したデータのキャッシュが必要であり、複雑になる可能性があります。
専用のデータフェッチライブラリは、データの取得とキャッシュの難しい作業を代行し、アプリが必要とするデータとその表示方法に集中できるようにします。これらのライブラリは通常、コンポーネント内で直接使用されますが、より高速なプリフェッチとパフォーマンス向上のためにルーティングローダーに統合したり、サーバーサイドレンダリングでも使用できます。
コンポーネント内で直接データをフェッチすると、ネットワークリクエストのウォーターフォールにより読み込み時間が遅くなる可能性があるため、可能な限りルーターのローダーやサーバー上でデータをプリフェッチすることをお勧めします！これにより、ページが表示される際にページのデータを一度にすべてフェッチできます。
ほとんどのバックエンドやRESTスタイルのAPIからデータをフェッチする場合は、以下を使用することをお勧めします：
GraphQL APIからデータをフェッチする場合は、以下を使用することをお勧めします：
コード分割
コード分割は、アプリをオンデマンドで読み込める小さなバンドルに分割するプロセスです。アプリのコードサイズは、新機能や追加の依存関係ごとに増加します。アプリ全体のコードをすべて送信する必要があるため、アプリの読み込みが遅くなる可能性があります。キャッシュ、機能/依存関係の削減、一部のコードをサーバーで実行するように移行することは、読み込みの遅さを緩和するのに役立ちますが、過度に使用すると機能を犠牲にする不完全な解決策です。
同様に、フレームワークを使用するアプリにコード分割を依存させると、コード分割が行われていない場合よりも読み込みが遅くなる状況に遭遇する可能性があります。例えば、遅延読み込みされたチャートは、チャートをレンダリングするために必要なコードの送信を遅らせ、チャートコードをアプリの残りの部分から分割します。ParcelはReact.lazyによるコード分割をサポートしています。しかし、チャートがそのデータを最初にレンダリングされた後に読み込む場合、今や二度待つことになります。これはウォーターフォールです：チャートのデータをフェッチし、それをレンダリングするコードを同時に送信するのではなく、各ステップが次々に完了するのを待たなければなりません。
バンドリングとデータフェッチと統合されたルートによるコード分割は、アプリの初期読み込み時間と、アプリの最大の可視コンテンツがレンダリングされるまでの時間（Largest Contentful Paint）を短縮できます。
コード分割の手順については、ビルドツールのドキュメントを参照してください：
アプリケーションパフォーマンスの向上
選択したビルドツールがシングルページアプリケーション（SPA）のみをサポートしているため、サーバーサイドレンダリング（SSR）、静的サイト生成（SSG）、および/またはReact Server Components（RSC）などの他のレンダリングパターンを実装する必要があります。最初はこれらの機能が必要なくても、将来的にはSSR、SSG、またはRSCの恩恵を受けるルートが存在する可能性があります。
- シングルページアプリケーション (SPA)は、単一のHTMLページを読み込み、ユーザーがアプリと対話するにつれてページを動的に更新します。SPAは始めやすいですが、初期読み込み時間が遅くなる可能性があります。SPAは、ほとんどのビルドツールのデフォルトのアーキテクチャです。
- ストリーミングサーバーサイドレンダリング (SSR)は、サーバー上でページをレンダリングし、完全にレンダリングされたページをクライアントに送信します。SSRはパフォーマンスを向上させることができますが、シングルページアプリよりもセットアップと維持が複雑になる可能性があります。ストリーミングを追加すると、SSRのセットアップと維持は非常に複雑になる可能性があります。詳細はViteのSSRガイドを参照してください。
- 静的サイト生成 (SSG)は、ビルド時にアプリの静的HTMLファイルを生成します。SSGはパフォーマンスを向上させることができますが、サーバーサイドレンダリングよりもセットアップと維持が複雑になる可能性があります。詳細はViteのSSGガイドを参照してください。
- React Server Components (RSC)は、ビルド時、サーバー専用、およびインタラクティブなコンポーネントを単一のReactツリー内で混在させることができます。RSCはパフォーマンスを向上させることができますが、現在のところセットアップと維持には高度な専門知識が必要です。詳細はParcelのRSC例を参照してください。
レンダリング戦略はルーターと統合する必要があり、フレームワークで構築されたアプリはルートごとにレンダリング戦略を選択できるようにする必要があります。これにより、アプリ全体を書き直すことなく、異なるレンダリング戦略を有効にできます。例えば、アプリのランディングページは静的生成 (SSG) の恩恵を受ける可能性があり、コンテンツフィードのあるページはサーバーサイドレンダリングで最高のパフォーマンスを発揮する可能性があります。
適切なルートに適切なレンダリング戦略を使用することで、コンテンツの最初のバイトが読み込まれるまでの時間 (Time to First Byte)、最初のコンテンツがレンダリングされるまでの時間 (First Contentful Paint)、およびアプリの最大の可視コンテンツがレンダリングされるまでの時間 (Largest Contentful Paint) を短縮できます。
そしてさらに…
これらは、新規アプリがゼロから構築する際に考慮する必要がある機能のほんの数例です。遭遇する多くの制限は、各問題が他の問題と相互に関連しており、馴染みのない問題領域での深い専門知識を必要とする可能性があるため、解決が難しい場合があります。
これらの問題を自分で解決したくない場合は、これらの機能をすぐに提供するフレームワークを使って始めることができます。