はじめに

約 10 年前にソフトウェア開発者としての道を歩み始めてからは、HTML、CSS、JavaScript、およびいくつかの Python 2 スクリプトをコーディングするだけでした。その間、私たちはサーバー側(cè)のクライアント/サーバー通信には PHP と SQL のみに依存していました。その次のレベルは、狀態(tài)や効果による変化に反応するといった魔法の言葉「React」です。これは、Facebook のエンジニアが作ったという噂によるもので、本件については深く掘り下げることなく、私の理解です。これは、フロントエンド部分のコーディングに使用していた方法では爆弾でした。

ソフトウェア開発が進(jìn)化し、バックエンド システムが複雑になるにつれて、React Server Components (RSC) はエコシステムの進(jìn)化が切実に必要であると感じました。それは、大規(guī)模な JavaScript バンドルと「読み込み」スピナーがいたるところにあった時代を思い出させます。 RSC がどのようにゲームを変えているかを見てみましょう。

パフォーマンス革命

RSC がもたらす主な変化は技術(shù)的なものだけでなく、哲學(xué)的なものでもあります。 RSC を使用すると、コンポーネント ツリー全體をクライアントに送信するのではなく、React で気に入っている対話性を維持しながら、サーバー上でコンポーネントをレンダリングできます。以前はダッシュボード アプリケーションを RSC に移行していましたが、非常にシンプルで、この世のものとは思えません。ダッシュボード アプリケーションのサイズは 60% 減少しました。

これは私が最近遭遇した実際の例です:

 // Before: Client Component
 import { ComplexDataGrid } from 'heavy-grid-library';
import { format } from 'date-fns';

export default function Dashboard() {
  const [data, setData] = useState([]);

  useEffect(() => {
    fetchDashboardData().then(setData);
  }, []);

  return <ComplexDataGrid data={data} />;
}

この従來のクライアント側(cè)のアプローチでは、いくつかのことが起こります。

• クライアント JavaScript にバンドルされる重いデータ グリッド ライブラリをインポートしています。
• useState を使用して、ブラウザー內(nèi)でデータをローカルに管理しています。
• コンポーネントのマウント後に useEffect を使用してデータを取得しています。
• データがフェッチされている間、ユーザーには読み込み狀態(tài)が表示されます。
• すべてのデータ処理はブラウザ內(nèi)で行われるため、ユーザーのデバイスの速度が低下する可能性があります。

次に、RSC のバージョンを見てみましょう:

import { sql } from '@vercel/postgres';
import { DataGrid } from './DataGrid';

export default async function Dashboard() {
  const data = await sql`SELECT * FROM dashboard_metrics`;

  return <DataGrid data={data} />;
}

• コンポーネントはデフォルトで非同期です。useEffect や useState は必要ありません。
• サーバー側(cè)クエリによる直接データベース アクセス。
• クライアント側(cè)のデータ取得コードは必要ありません。
• 初期データにはゼロロード狀態(tài)が必要です。
• データ処理はユーザーのデバイスではなく強力なサーバーで行われます。
• インポートされた DataGrid コンポーネントは、データの取得ではなく表示のみを処理する必要があるため、はるかに軽量になります。

その変化は驚くべきものです。 useEffect もクライアント側(cè)のデータ取得も不要になり、最も重要なことに、クライアントへの JavaScript の不必要な送信も不要になります。

現(xiàn)実世界の利點

その影響は単なるパフォーマンス指標(biāo)にとどまりません。 RSC を使用していると、データベース クエリがデータ ソースの近くで行われるようになり (上記の例では、コーディングのベスト プラクティスではありません)、コンポーネントがよりシンプルで焦點が絞られ、認(rèn)証と認(rèn)可のパターンがより単純になり、SEO が強化されていることに気づきました。改善はほぼ無料で行われますが、これは React の世界では以前には起こらなかったことです。

しかし、最も重要な利點は開発者のエクスペリエンスです。データベースに直接アクセスできる (安全!) コンポーネントを作成することは、スーパーパワーのように感じられます。これは、React のコンポーネントベースのアーキテクチャと、Next.js

による最先端のサーバーサイド レンダリングによるパフォーマンスの利點の両方の長所を併せ持つようなものです。

トレードオフ

正直に言うと、RSC は完璧ではありません。メンタル モデルを把握するには、特にクライアントとサーバーの境界を理解するには時間がかかります。私にとっては、ブラックボックス內(nèi)での一種の複雑な操作です。前回の移行例に従いますが、RSC 互換ではないサードパーティのライブラリでいくつかの障害に遭遇しました。解決策は？ハイブリッド アプローチ:

 // Before: Client Component
 import { ComplexDataGrid } from 'heavy-grid-library';
import { format } from 'date-fns';

export default function Dashboard() {
  const [data, setData] = useState([]);

  useEffect(() => {
    fetchDashboardData().then(setData);
  }, []);

  return <ComplexDataGrid data={data} />;
}

このハイブリッド アプローチで何が起こっているのかを詳しく見てみましょう:

• use client ディレクティブは、SearchFilter をクライアント コンポーネントとして明示的にマークします。
• SearchFilter は、クライアントでのみ発生するユーザー インタラクション (onChange イベント) を処理します。
• ProductList はサーバー コンポーネントのままで、サーバー側(cè)でデータを取得します。
• コンポーネントの構(gòu)成により、必要に応じてサーバーとクライアントのレンダリングを混在させることができます。
• 対話型部分 (SearchFilter) のみが JavaScript をクライアントに伝えます。
• データ量の多い部分 (製品を含む ProductGrid) はサーバー上でレンダリングされます。

結(jié)論 (未來はサーバーファースト)

RSC は単なる新機能ではなく、React アプリケーションの構(gòu)築方法に伝わるパラダイムです。 React のコンポーネント モデルを維持しながら、高価な計算とデータのフェッチをサーバーに移動できる機能は革新的です。

RSC は、データ量の多いアプリケーションを構(gòu)築しているチームに、開発者のエクスペリエンスを犠牲にすることなくパフォーマンスを向上させる道を提供します。環(huán)境が成熟し、より多くのライブラリが RSC 互換になるにつれて、このパターンが React アプリケーションを構(gòu)築するデフォルトの方法になると予想しています。

あなたの経験を共有してください

プロジェクトで React Server コンポーネントの使用を開始しましたか?以下のコメント欄で、挑戦や勝利についての意見をお待ちしています。
この記事が RSC についての理解を深めるのに役立った場合は、?? を付けてください。最新のシステムについてさらに詳しく知るために、私をフォローすることを忘れないでください。

著者について

Ivan Duarte は、フリーランスで働いた経験を持つバックエンド開発者です。彼は Web 開発と人工知能に情熱を持っており、チュートリアルや記事を通じて知識を共有することを楽しんでいます。さらに詳しい情報や最新情報を得るには、X、Github、LinkedIn で私をフォローしてください。

? ニュースレターを購読する

ByteUp の記事を受信箱で直接読んでください。

ニュースレターを購読して、お見逃しなく。

? 今すぐ購読 ?

以上がReact サーバー コンポーネント: 進(jìn)化の詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國語 Web サイトの他の関連記事を參照してください。