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

'use client'

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>
}

'use server'

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 داشتیم اما یک فرق اساسی اینجا وجود داره که خیلی کوتاه بهش اشاره میکنم. قبل از معرفی server component ها ما مجبور بودیم همه ی داده هایی که صفحه ی ما نیاز داشت و قصد داشتیم در لود اولیه صفحه داشته باشیم را قبل از هرچیزی کامل لود کنیم، یعنی فرض کنید شما میخواهید به صفحه ای که از قبل داشتید یک بخش جدید اضافه کنید، اونوقت مجبور بودید برای خواندن اطلاعات مورد نیاز آن بخش بیاید اطلاعات اون رو در تابع getServerSideProps بخوانید و به کل صفحه پاس بدید و دوباره از صفحه به خود کامپوننت. این کار اشکالات پترنی مثل prop drilling و tight coupling ایجاد میکنه و کد ما سنگین, اشتباه پذیر و سخت نگهداری میشه. اما هر server component فارق از اینکه تو چه صفحه ای استفاده شده، داده خودش رو درون خودش لود میکنه و دیگر نیاز نیست داده از چند لایه از بالا به پایین پاس داده بشه. برای مثال:
 

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,
     postgres://user:pass@localhost:5432/dbname });
     await client.connect();
     const res = await client.query("SELECT id, name, email FROM users");
     await client.end(); 
     
     return ( Users
       {res.rows.map((u) => (
        {u.name} ({u.email})
       ))}
     );
    }

   Expand code
2. حجم کمتر باندل(bundle): به دلیل اینکه تمام کد های رندرینگ سمت سرور انجام میشه بنابراین برای اونها هیچ کد جاوااسکریپتی سمت کاربر ایجاد نمیشه که هم به لود کمتر شبکه کمک میکنه و چون دیگه ما مرحله hydration رو نداریم، سایت ما بار کمتری روی سیستم کاربر قرار میده. (توجه کنید که ما هیچ رویداد جاواسکریپتی (مثل onClick, onChange و…) روی المان های داخل RSC نداریم.)
3. Caching در سطح کامپوننت های 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 (به‌خصوص UI-ها) روی useEffect، window، document، رویدادها و… حساب کردن؛ یعنی ذاتاً کلاینتی‌ان.
4. دیباگ سخت‌تر: DevTools, logging, stack trace و… وقتی بین سرور و کلاینت split می‌شن، ترَک کردن اینکه یک مشکل دقیقاً کجای chain اتفاق افتاده سخت‌تره (سرور؟ استریم؟ کلاینت؟)