微修正

Author: smikitky

src/content/learn/build-a-react-app-from-scratch.md

@@ -12,11 +12,11 @@ title: ゼロからの React アプリ構築
 
 #### まずはフレームワーク使用の検討を {/*consider-using-a-framework*/}
 
-ゼロから始めるのは React を使い始める簡単な方法ですが、この方法を選ぶ際は、これがその場限りの独自フレームワークを構築しているのと変わらない、という重要なトレードオフについて認識してください。アプリの要件が進化するにつれ、推奨フレームワークがすでに開発済みでうまくサポートしているような、よりフレームワーク的な問題について、自前で解決する必要が出てくるかもしれません。
+React の始め方としてゼロからスタートするのは簡単ですが、このアプローチを選ぶ際の重要なトレードオフとして、これがその場限りの独自フレームワークを構築しているのと変わらないのだ、ということを認識してください。アプリの要件が進化するにつれ、推奨フレームワークならすでにうまく開発もサポートもしているような、よりフレームワーク的な問題について、自前で解決する必要が出てくるかもしれません。
 
-たとえば、将来的にアプリがサーバサイドレンダリング (SSR)、静的サイト生成 (SSG)、または React サーバコンポーネント (RSC) のサポートを必要とする場合、それらを自前で実装しなければなりません。同様に、フレームワークレベルでの統合を必要とする将来の React 機能を使用したい場合、それらも自分で実装しなければなりません。
+たとえば、将来的にアプリがサーバサイドレンダリング (SSR)、静的サイト生成 (SSG)、または React Server Components (RSC) のサポートを必要とする場合、それらを自前で実装しなければなりません。同様に、フレームワークレベルでの統合を必要とする将来の React 機能を使用したい場合、それらも自分で実装しなければなりません。
 
-私たちが推奨するフレームワークは、よりパフォーマンスの良いアプリを構築するのにも役立ちます。たとえば、ネットワークリクエストのウォーターフォールを減らしたり排除したりすることで、より良いユーザ体験を提供します。小さなプロジェクトを構築している間は優先度が低いかもしれませんが、アプリにユーザが増えていけばパフォーマンスを向上させたいと思うかもしれません。
+私たちが推奨するフレームワークは、よりパフォーマンスの良いアプリを構築するのにも役立ちます。たとえば、ネットワークリクエストのウォーターフォールを減らしたり排除したりすることで、より良いユーザ体験を提供します。小さなプロジェクトを構築している間は優先度が低いかもしれませんが、アプリにユーザが増えていけばパフォーマンスを向上させたいと思うことでしょう。
 
 またこのアプローチでは、ルーティングやデータフェッチ、その他の機能の開発のされ方があなたの事情に特有のものになるため、サポートを受けるのも難しくなります。これらの問題に自分で取り組むことに自信がある場合、または将来的にもこれらの機能が必要になることはないと確信している場合にのみ、このオプションを選ぶようにすべきです。
 
@@ -89,7 +89,7 @@ React エコシステムには、これらの問題に対するツールがた
 
 ### データフェッチ {/*data-fetching*/}
 
-サーバやその他のデータソースからデータを取得することは、ほとんどのアプリケーションにおいて重要な作業です。これを適切に行うには、読み込み中状態の管理、エラー状態の管理、および取得したデータのキャッシュ管理が必要であり、複雑になることがあります。
+サーバやその他のデータソースからデータを取得することは、ほとんどのアプリケーションにおいて重要な作業です。これを適切に行うには、ローディング状態の管理、エラー状態の管理、および取得したデータのキャッシュ管理が必要であり、複雑になりがちです。
 
 この目的に特化したデータフェッチライブラリは、データの取得とキャッシュに関する難しい作業を行ってくれるため、あなたはアプリが必要とするデータとその表示方法に集中できます。これらのライブラリは通常、コンポーネント内で直接使用されますが、ルーティングのローダに統合して高速な事前取得とパフォーマンスの向上を図ることもでき、サーバレンダーにも利用できます。
 
@@ -111,7 +111,7 @@ GraphQL API からデータを取得する場合、以下の使用をお勧め
 
 コード分割 (code splitting) とは、オンデマンドで読み込める小さな複数のバンドルへとアプリを分割するための作業です。アプリのコードサイズは、新しい機能や依存ライブラリを追加するたびに増加します。実際に使用する前にアプリ全体のコードをすべて送信する必要がある場合、読み込みが遅くなることがあります。キャッシュ、機能や依存ライブラリの削減、一部コードのサーバ側実行といった方法で読み込みの遅さを軽減することもできますが、これらは過度に使用すると機能性を犠牲にしてしまう不完全な解決策です。
 
-同様に、アプリが使っている独自フレームワークにコード分割を任せていると、コード分割がまったく行われていない場合よりも読み込みが遅くなるという状況に遭遇することがあります。たとえば、[遅延読み込み](/reference/react/lazy)でチャートを読み込むようにした場合、チャートコードをアプリの残りの部分から分離し、チャートのレンダーに必要なコードの送信を遅延させることができます。[Parcel は React.lazy を使用したコード分割をサポートしています](https://parceljs.org/recipes/react/#code-splitting)。ところが、チャート自身が初回レンダー後にデータを読み込んでいる場合、2 回待つことになります。これがウォーターフォールです。チャートのためのデータとそれを表示するためのコードを同時にフェッチするのではなく、各ステップが順番に完了するのを待たなければならないという状況です。
+また、アプリが使っている独自フレームワークにコード分割を任せていると、コード分割がまったく行われていない場合より却って読み込みが遅くなるという状況に遭遇することがあります。例えば、チャートの[遅延読み込み](/reference/react/lazy)を使えば、チャートのコードをアプリの他の部分から分離し、チャートのレンダーに必要なコードだけ送信を遅らせることができます。[Parcel は React.lazy を使用したコード分割をサポートしています](https://parceljs.org/recipes/react/#code-splitting)。ところが、チャートのコード自身が初回レンダー後にデータを読み込む場合、2 回の待機が発生することになります。これがウォーターフォールです。チャートデータとそれを表示するためのコードを同時にフェッチするのではなく、各ステップが順番に完了するのを待たなければならないという状況です。
 
 ルートごとにコードを分割するだけでなく、バンドルやデータフェッチと統合することで、アプリの初期読み込み時間とアプリの最大可視コンテンツのレンダー時間 ([Largest Contentful Paint](https://web.dev/articles/lcp)) を短縮できます。