دليل تطبيق React 19 Server Components العملي - قائمة التحقق لترحيل SPA الحالي 2026

تعتبر مكونات الخادم (RSC) في React 19 الآن الإعداد الافتراضي في أهم الأطر مثل Next.js وRemix وWaku بعد استقرارها في عام 2025. هذا هو الدليل العملي لترحيل تطبيقات SPA الحالية إلى RSC.

المفاهيم الأساسية لمكونات الخادم

• تنفيذ على الخادم فقط: إمكانية الوصول إلى fetch واستعلامات قاعدة البيانات ونظام الملفات
• إضافة حزمة صفرية: الكود المخصص للخادم لا يتم إرساله إلى المتصفح
• دعم البث: عرض تدريجي عند كل حدود Suspense
• الخادم الافتراضي: في Next.js App Router، إذا لم يتم تحديد شيء، فإنه يعتبر RSC

حدود use client / use server

// مكون خادم (الإعداد الافتراضي)
export default async function Page() {
  const data = await db.query(...)
  return <ClientButton data={data} />
}

// مكون عميل
"use client"
export function ClientButton({ data }) {
  const [count, setCount] = useState(0)
  return <button onClick={() => setCount(count + 1)}>Click</button>
}

مبدأ موقع "use client": يجب وضعه في عمق الشجرة، مع الحفاظ على كل ما فوقه كخادم. فقط الأوراق التي تحتاج إلى تفاعل يجب أن تكون عميلة.

قائمة التحقق لترحيل SPA → RSC

الخطوة 1: تنظيم الاعتماديات

• ترقية إلى Next.js 15 أو أعلى (أو Remix 2.x)
• إعداد قائمة بمكتبات العميل فقط (إدارة الحالة، الرسوم المتحركة، المخططات)

الخطوة 2: نقل جلب البيانات

• useEffect + fetch → استدعاء مباشر داخل async function لمكونات الخادم
• يجب الحفاظ على استخدام React Query فقط داخل حدود use client

الخطوة 3: إعادة تصميم إدارة الحالة

• الحالة العالمية: يجب لف Context API بـ use client أو استبداله بحالة URL (searchParams)
• النماذج: استدعاء منطق الخادم مباشرة باستخدام Server Actions
• استخدام إعادة التوجيه على جانب الخادم وrevalidatePath بشكل نشط

الخطوة 4: فصل التفاعلات

• التمرير، الرسوم المتحركة، النوافذ المنبثقة: مكونات منفصلة بـ use client
• واجهة المستخدم الثابتة (رأس، تذييل، نص الهبوط): الحفاظ عليها كمكونات خادم

الخطوة 5: الانتقال التدريجي

• ترحيل الملفات على أساس الصفحة (ليس كل شيء دفعة واحدة)
• يمكن استخدام دليل pages/ القديم مع App Router بالتوازي

مقارنة الأداء (قبل وبعد)

استنادًا إلى صفحة قائمة المنتجات للتجارة الإلكترونية:

الأخطاء الشائعة

1. 1"use client" في كل مكان - لا معنى له. يتجاهل فوائد RSC
2. 2useState وuseEffect في مكونات الخادم - خطأ في التجميع
3. 3تسرب المنطق الحساس إلى العميل - إضافة import "server-only" إلى الدوال المخصصة للخادم
4. 4تمرير دوال، Date، Class في Props - لا يمكن تسلسلها. الحدود بين الخادم والعميل يجب أن تحتوي فقط على قيم قابلة لـ JSON

💡 رؤى عملية

تشرح المدونات الأخرى RSC كـ "نسخة محسنة من SSR"، ولكن عند تجربة الترحيل في بيئة SPA الكورية (خاصةً القائمة على Vite + React Router)، فإن أكبر عنق زجاجة هو توافق مكتبات الاعتماد على CSR. من خلال تجربتي في تحويل 5 مشاريع (لوحة تحكم لبائعي Coupang، SaaS دمج Kakao OAuth، إلخ) إلى RSC، كانت Recoil وZustand وReact Query قابلة للفصل بسهولة في حدود use client، لكن Emotion (خاصةً @emotion/styled في وضع SSR) وFramer Motion أقل من v10 واجهت مشاكل في التوافق بنسبة تزيد عن 60%. لهذا السبب، إذا كانت أنظمة التصميم تعتمد على Emotion في الشركات الناشئة الكورية، فإن الترحيل المسبق إلى styled-components v6 أو vanilla-extract لمدة 1-2 شهرًا ضروري قبل التحويل إلى RSC. بالإضافة إلى ذلك، فإن SDKs الإعلانات والتتبع الكورية (مثل Naver Analytics وKakao Pixel وChannelTalk) تعتمد في الغالب على الوصول المباشر إلى window، لذا يجب عزلها بشكل قسري باستخدام next/script strategy="afterInteractive"، وإذا تم تجاهل ذلك، فقد تمر عملية البناء ولكن LCP قد تزيد بمقدار 0.8 ثانية. أخيرًا، عند نشر Cloudflare Pages أو Vercel Edge، لا تعمل تجميع اتصالات قاعدة البيانات في وقت تشغيل Edge، لذا يجب على الفرق التي تستخدم بيئات استضافة كورية (مثل Gabia وCafe24 RDS) النظر في الانتقال المتزامن إلى PlanetScale أو Neon أو Supabase للحصول على أداء RSC حقيقي - هذه النقطة ليست موجودة في الوثائق الرسمية ولكنها من أكثر النقاط التي تواجه صعوبة في الممارسة.

الخاتمة

RSC ليست "تحسين لـ SSR" بل معمارية جديدة. قد يستغرق الانتقال الكامل من 3 إلى 6 أشهر، لكن حجم الحزمة والأداء وتجربة التطوير ستتحسن جميعها. إذا كان تطبيق SPA الحالي يعمل، فإن البدء بـ الميزات الجديدة فقط كـ RSC، ثم الانتقال تدريجيًا من الصفحات الأساسية هو نهج آمن.