| title | ゼロからの React アプリ構築 |
|---|
あなたのアプリが既存のフレームワークではうまく対応できない制約を有している場合や、自分自身でフレームワークを構築したい場合、または React アプリの基本を学びたい場合は、ゼロから React アプリを構築することも可能です。
React の始め方としてゼロからスタートするのは簡単ですが、このアプローチを選ぶ際の重要なトレードオフとして、これがその場限りの独自フレームワークを構築しているのと変わらないのだ、ということを認識してください。アプリの要件が進化するにつれ、推奨フレームワークならすでにうまく開発もサポートもしているような、よりフレームワーク的な問題について、自前で解決する必要が出てくるかもしれません。
たとえば、将来的にアプリがサーバサイドレンダリング (SSR)、静的サイト生成 (SSG)、または React Server Components (RSC) のサポートを必要とする場合、それらを自前で実装しなければなりません。同様に、フレームワークレベルでの統合を必要とする将来の React 機能を使用したい場合、それらも自分で実装しなければなりません。
私たちが推奨するフレームワークは、よりパフォーマンスの良いアプリを構築するのにも役立ちます。たとえば、ネットワークリクエストのウォーターフォールを減らしたり排除したりすることで、より良いユーザ体験を提供します。小さなプロジェクトを構築している間は優先度が低いかもしれませんが、アプリにユーザが増えていけばパフォーマンスを向上させたいと思うことでしょう。
またこのアプローチでは、ルーティングやデータフェッチ、その他の機能の開発のされ方があなたの事情に特有のものになるため、サポートを受けるのも難しくなります。これらの問題に自分で取り組むことに自信がある場合、または将来的にもこれらの機能が必要になることはないと確信している場合にのみ、このオプションを選ぶようにすべきです。
推奨フレームワークのリストについては、React アプリの作成をご覧ください。
最初のステップは、vite、parcel、または rsbuild のようなビルドツールをインストールすることです。これらのビルドツールは、ソースコードをパッケージ化して実行する機能、ローカル開発用の開発サーバ、およびアプリを本番サーバにデプロイするためのビルドコマンドを提供します。
Vite は、モダンなウェブプロジェクトのために素早くかつスリムな開発体験を提供することを目指したビルドツールです。
{`npm create vite@latest my-app -- --template react`}Vite はデフォルトで適切な設定がされた、使い方に規約がある (opinionated) ツールです。Vite には、ファストリフレッシュ、JSX、Babel/SWC、その他の一般的な機能をサポートする豊富なプラグインのエコシステムがあります。Vite の React プラグインや React SWC プラグイン、React SSR のサンプルプロジェクト を参照して始めてみてください。
Vite は、推奨フレームワーク のひとつである React Router でもビルドツールとして使用されています。
Parcel は、素晴らしい初期開発体験とスケーラブルなアーキテクチャの両方を備えており、プロジェクトを始めたばかりの状態から大規模な本番アプリケーションにまで成長させることができます。
{`npm install --save-dev parcel`}Parcel は、ファストリフレッシュ、JSX、TypeScript、Flow、スタイリングをデフォルトでサポートしています。Parcel の React レシピを参照して始めてみてください。
Rsbuild は、Rspack を基にしたビルドツールで、React アプリケーションのためのシームレスな開発体験を提供します。慎重に調整されたデフォルト設定とパフォーマンス最適化が最初から利用できます。
{`npx create-rsbuild --template react`}Rsbuild には、ファストリフレッシュ、JSX、TypeScript、スタイリングなどの React 機能のサポートが組み込まれています。Rsbuild の React ガイドを参照して始めてみてください。
<<<<<<< HEAD React Native をゼロから始める場合は、React Native 用の JavaScript バンドラである Metro を使用する必要があります。Metro は iOS や Android などのプラットフォーム向けのバンドル機能をサポートしていますが、上記で紹介したツールと比較すると多くの機能が不足しています。プロジェクトが React Native のサポートを必要としているのでない限り、Vite、Parcel、または Rsbuild から始めることをお勧めします。
If you're starting from scratch with React Native you'll need to use Metro, the JavaScript bundler for React Native. Metro supports bundling for platforms like iOS and Android, but lacks many features when compared to the tools here. We recommend starting with Vite, Parcel, or Rsbuild unless your project requires React Native support.
5138e605225b24d25701a1a1f68daa90499122a4
上記のビルドツールを使うとクライアントのみのシングルページアプリ (SPA) から始まりますが、それ以上のもの、つまりルーティング、データフェッチ、スタイリングといった一般的な機能に対するソリューションは含まれていません。
React エコシステムには、これらの問題に対するツールがたくさん存在します。手始めとして、ここでは広く使用されているものをいくつか紹介していますが、他のツールがあなたにとってより適している場合は自由に選んでください。
ルーティング (routing) は、ユーザが特定の URL にアクセスしたときにどのコンテンツやページを表示するかを決定するものです。ある URL をアプリの異なる部分にマッピングするために、ルータの設定が必要です。また、ネストされたルート、ルートパラメータ、クエリパラメータを処理する必要があります。ルータはコード内で設定することも、コンポーネントのフォルダやファイル構造に基づいて定義することもできます。
ルータは現代のアプリケーションの中核をなす部分であり、通常はデータフェッチ（ページ全体のデータの高速なプリフェッチを含む）、コード分割（クライアントのバンドルサイズを最小化する）、およびページのレンダー方法（各ページがどのように生成されるかを決定する）と統合されています。
以下のライブラリの使用をお勧めします。
サーバやその他のデータソースからデータを取得することは、ほとんどのアプリケーションにおいて重要な作業です。これを適切に行うには、ローディング状態の管理、エラー状態の管理、および取得したデータのキャッシュ管理が必要であり、複雑になりがちです。
この目的に特化したデータフェッチライブラリは、データの取得とキャッシュに関する難しい作業を行ってくれるため、あなたはアプリが必要とするデータとその表示方法に集中できます。これらのライブラリは通常、コンポーネント内で直接使用されますが、ルーティングのローダに統合して高速な事前取得とパフォーマンスの向上を図ることもでき、サーバレンダーにも利用できます。
コンポーネント内で直接データを取得すると、ネットワークリクエストのウォーターフォールに伴う遅延が発生し、読み込み時間が遅くなる可能性があることに注意してください。可能な限り、ルータローダやサーバで、データを事前フェッチすることをお勧めします！ これによりページの表示とページデータの取得をまとめて同時に行うことができます。
ほとんどのデータをバックエンドや REST スタイルの API から取得している場合、以下のライブラリの使用をお勧めします。
GraphQL API からデータを取得する場合、以下の使用をお勧めします。
コード分割 (code splitting) とは、オンデマンドで読み込める小さな複数のバンドルへとアプリを分割するための作業です。アプリのコードサイズは、新しい機能や依存ライブラリを追加するたびに増加します。実際に使用する前にアプリ全体のコードをすべて送信する必要がある場合、読み込みが遅くなることがあります。キャッシュ、機能や依存ライブラリの削減、一部コードのサーバ側実行といった方法で読み込みの遅さを軽減することもできますが、これらは過度に使用すると機能性を犠牲にしてしまう不完全な解決策です。
また、アプリが使っている独自フレームワークにコード分割を任せていると、コード分割がまったく行われていない場合より却って読み込みが遅くなるという状況に遭遇することがあります。例えば、チャートの遅延読み込みを使えば、チャートのコードをアプリの他の部分から分離し、チャートのレンダーに必要なコードだけ送信を遅らせることができます。Parcel は React.lazy を使用したコード分割をサポートしています。ところが、チャートのコード自身が初回レンダー後にデータを読み込む場合、2 回の待機が発生することになります。これがウォーターフォールです。チャートデータとそれを表示するためのコードを同時にフェッチするのではなく、各ステップが順番に完了するのを待たなければならないという状況です。
ルートごとにコードを分割するだけでなく、バンドルやデータフェッチと統合することで、アプリの初期読み込み時間とアプリの最大可視コンテンツのレンダー時間 (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) を短縮できるのです。
これらは、新しいアプリをゼロから構築する際に考慮すべき機能のほんの一例です。あなたが直面するであろう多くの問題は、それぞれが他の問題と相互に関連しており、不慣れな領域での深い専門知識を必要とする場合もあるため、解決が難しいことがあります。
これらの問題を自分で解決したくない場合は、これらの機能をデフォルトで利用できるフレームワークで始めることができます。