React Server Component ها در نسخه 19 ری‌اکت معرفی شدند و قابلیت های جدید و متنوعی رو مهیا کردن. بطور ساده این کامپوننت ها میتونن در بک اند بطور مستقیم داده ی مورد نیازشون رو بخونن یا با هر سرویس دیگری در بک اند ارتباط برقرار کنن; مثل خوندن داده ها مستقیم از دیتابیس.

مثلا به کد زیر توجه کنید که چه مقدار کد نوشته شده برای Server Component ساده تر شده.

'use client'

import { useState, useEffect } from 'react'

export function ClientComponent() {
  const [data, setData] = useState(null)
  const [loading, setLoading] = useState(true)
  const [error, setError] = useState(false)
  
  useEffect(() => {
    setLoading(true)
    setData(undefined)
    setError(false)
    fetch("/api/data")
      .then(res => res.json())
      .then(data => setData(data))
      .catch(error => setError(true))
  }, [])
  
  if (loading) return <p>Loading...</p>
  if (error) return <p>Error</p>
  return <p>{data}</p>
}

export async function ServerComponent() {
  try {
    const data = await fetch("/api/data").then(res => res.json())
    return <p>{data}</p>
  } catch (error) {
    return <p>Error</p>
  }
}

در کد بالا با منطق ساده خواندن و نمایش اطلاعات، خوانایی کد ما خیلی بهتر شده و این فقط به کد نویسی ساده تر منتهی نمیشه. در server component فرآیند خواندن داده و رندر html در سمت سرور انجام میشه و کاربر نهایی به سرعت و بدون نیاز به خواندن داده و رندر در سمت کلاینت، فورا نتیجه رو مشاهده میکنه که این قضیه به بهبود لود صفحه و سئو وبسایت ما کمک میکنه. خب ما در فریمورک های با پشتیبانی ssr مثل next js قبلا هم server rendering داشتیم اما یک فرق اساسی اینجا وجود داره که خیلی کوتاه بهش اشاره میکنم.

1. Waterfall: باید صبر میکردیم تمام دادههای صفحه لود شه تا چیزی به کاربر نشان بدیم. اما در RSF با استفاده تکنیک streaming هر تکه از صفحه مجزا لود میشه.
2. Prop Drilling: داده را باید در ریشه صفحه میگرفتیم و لایه به لایه به پایین پاس میدادیم. (در نکست getServerSideProps)
3. Tight Coupling: کامپوننت فرزند به والد وابسته بود.

اما در RSC، هر کامپوننت مسئول داده خودش هست. اگر Sidebar نیاز به لیست منو ها داره، خودش مستقیماً اون را از دیتابیس یا API میخونه و کاری به صفحه اصلی نداره.
 

export default async function Sidebar() {
	const cats = await db.category.findMany();
	// rest of the code...
}

مزایای دیگر RSC:

1. امنیت: با توجه به اینکه کد های RSC سمت سرور اجرا میشن دیگه نیازی به نگرانی بابت leak/لو رفتن توکن ندارید و حتی میتونید مستقیم با دیتابیس در ارتباط باشید و کل پروژه رو روی این استک بنویسید. برای مثال:

   import { Client } from "pg";
   
   export default async function UsersPage() {
     const client = new Client({ connectionString: process.env.DATABASE_URL });
     await client.connect();
     const res = await client.query("SELECT id, name, email FROM users");
     await client.end(); 
     
     return res.rows.map((u) => (
        {u.name} ({u.email})
       ));
    }

   Expand code
2. حجم کمتر باندل(bundle): به دلیل اینکه تمام کد های رندرینگ سمت سرور انجام میشه بنابراین برای اونها هیچ کد جاوااسکریپتی سمت کاربر ایجاد نمیشه که هم به لود کمتر شبکه کمک میکنه و چون دیگه ما مرحله hydration رو نداریم، سایت ما بار کمتری روی سیستم کاربر قرار میده. (توجه کنید که ما هیچ رویداد جاواسکریپتی (مثل onClick, onChange و…) روی المان های داخل RSC نداریم.)

معایب RSC:

1. مدل ذهنی جدید: برای تیم‌هایی که سال‌ها با React سنتی کار کردن، این سوییچ ذهنی و تغییر best practice‌ها (data fetching، state، ساختار درخت کامپوننت‌ها) کار رو سخت‌تر و کندتر می‌کنه.
2. interactivity محدود داخل RSC: خود Server Component اصلاً نمی‌تونه: event handler داشته باشه (onClick, onChange, …)، از useState و useEffect و… استفاده کنه و real-time UI update انجام بده.
   برای هر تعاملی باید یک Client Component بذاری وسط.
3. سازگاری کم‌تر با کتابخانه‌های شخص ثالث: خیلی از لایبرری‌های React از useEffect، window، document، رویدادها و… استفاده میکنن؛ یعنی ذاتاً کلاینتی‌ان و روی RSC جواب نمیدن.
4. دیباگ سخت‌تر: DevTools, logging, stack trace و… وقتی بین سرور و کلاینت split می‌شن، ترَک کردن اینکه یک مشکل دقیقاً کجای فرآیند اتفاق افتاده سخت‌تره (سرور یا کلاینت؟)