React Server Components: السر الذي حوّل تطبيقاتنا من بطيئة إلى فائقة السرعة دون تعقيد

كان يوم جمعة عادياً في مكتبنا، السيرفر ينهار تحت ضغط ٥٠٠ مستخدم متزامن، وواجهة المستخدم تتجمد كل ثلاث ثوانٍ. المشكلة؟ كنا نرسل ٣ ميجابايت من جافاسكريبت إلى المتصفح فقط لتشغيل صفحة بسيطة تعرض قائمة المنتجات. المطور الذي كتب الكود كان يعتقد أنه يتبع أفضل الممارسات: فصل المكونات، استخدام hooks، وحتى memoization لكل شيء. لكن الحقيقة المؤلمة هي أننا كنا نضرب أنفسنا بأيدينا. هذا هو اليوم الذي اكتشفنا فيه أن الريأكت التقليدية ليست الحل لكل شيء، وأن هناك ثورة اسمها React Server Components.

في هذا المقال، لن نتحدث عن تعريفات نظرية أو مميزات سطحية. سنغوص في أعماق React Server Components (RSC) لنفهم كيف تعمل حقاً، لماذا غيرت قواعد اللعبة، وأين تقع الفخاخ التي تجعل حتى المطورين المحترفين يفشلون في تطبيقها. سأريك كيف تحولنا من فريق يعاني من بطء السيرفر إلى فريق يبني تطبيقات فائقة الأداء دون تعقيد إضافي، وسأريك الأكواد الحقيقية التي استخدمناها وليس مجرد أمثلة تافهة.

لماذا كانت الريأكت التقليدية كابوساً للأداء؟

قبل RSC، كان كل مكون ريأكت يُرسل إلى المتصفح كجافاسكريبت قابل للتنفيذ. حتى المكونات البسيطة مثل زر أو بطاقة منتج كانت تتطلب تحميل كامل مكتبة الريأكت وتشغيلها في المتصفح. المشكلة الأكبر هي أننا كنا نكرر نفس الأخطاء مراراً: جلب البيانات داخل useEffect، استخدام مكتبات ضخمة مثل lodash في الكود الذي يُرسل إلى العميل، وحتى تنفيذ عمليات حسابية ثقيلة على المتصفح. كل هذا كان يؤدي إلى ما نسميه "جافاسكريبت أوفرلود"، حيث يصبح المتصفح بطيئاً حتى على أجهزة قوية.

لنأخذ مثالاً واقعياً من مشروع حقيقي عملنا عليه: تطبيق للتجارة الإلكترونية يحتوي على صفحة تعرض ٢٠ منتجاً. في الريأكت التقليدية، كنا نرسل ٤٠٠ كيلوبايت من جافاسكريبت فقط لتشغيل هذه الصفحة، منها ١٥٠ كيلوبايت لمكتبة axios لجلب البيانات، و٥٠ كيلوبايت لمكتبة تنسيق التواريخ، و٢٠٠ كيلوبايت للكود الخاص بالمكونات. المشكلة أن كل هذا الكود كان يُنفذ في المتصفح، حتى الأجزاء التي لا تحتاج إلى تفاعل المستخدم، مثل جلب البيانات وعرضها. هذا كان يؤدي إلى بطء في التحميل الأولي وتجمد في واجهة المستخدم عند التفاعل مع الصفحة.

// مثال تقليدي لمكون يعرض قائمة المنتجات
import { useState, useEffect } from 'react';
import axios from 'axios';
import { format } from 'date-fns';

function ProductList() {
 const [products, setProducts] = useState([]);
 const [loading, setLoading] = useState(true);

 useEffect(() => {
 axios.get('/api/products').then((response) => {
 setProducts(response.data);
 setLoading(false);
 });
 }, []);

 if (loading) return <div>جاري التحميل...</div>;

 return (
 <div>
 {products.map((product) => (
 <div key={product.id}>
 <h3>{product.name}</h3>
 <p>{format(new Date(product.createdAt), 'MMMM d, yyyy')}</p>
 </div>
 ))}
 </div>
 );
}

لاحظ كيف أن هذا الكود البسيط يتطلب تحميل مكتبات ضخمة في المتصفح، ويستخدم useEffect لجلب البيانات، مما يؤدي إلى حالة من "الوميض" عند التحميل. والأسوأ من ذلك، أن كل هذه العمليات تُنفذ في المتصفح، حتى لو كانت البيانات ثابتة ولا تتغير. هذا هو بالضبط ما تعالجه React Server Components.

ما هي React Server Components وكيف تعمل خلف الكواليس؟

React Server Components هي مكونات تُنفذ بالكامل على السيرفر ولا تُرسل أي جافاسكريبت إلى المتصفح. نعم، قرأت ذلك بشكل صحيح: لا جافاسكريبت على الإطلاق. هذا يعني أن المكون يُنفذ مرة واحدة على السيرفر، ويُرجع HTML جاهز للعرض، دون الحاجة إلى تحميل أي كود إضافي في المتصفح. الفكرة الأساسية هي أن ننفذ العمليات التي لا تتطلب تفاعلاً من المستخدم على السيرفر، مثل جلب البيانات، وتنسيق النصوص، وحتى العمليات الحسابية البسيطة.

لفهم كيف يعمل هذا، علينا أن نفهم الفرق بين نوعين من المكونات في تطبيقات RSC: Server Components وClient Components. Server Components تُنفذ على السيرفر وتُرجع HTML فقط، بينما Client Components هي المكونات التقليدية التي نعرفها وتُنفذ في المتصفح. السر هنا هو أن Server Components يمكنها جلب البيانات وتنفيذ العمليات دون الحاجة إلى إرسال أي كود إلى المتصفح، بينما Client Components تُستخدم فقط للأجزاء التي تتطلب تفاعلاً من المستخدم، مثل الأزرار والنماذج.

// Server Component: يُنفذ على السيرفر ولا يُرسل جافاسكريبت إلى المتصفح
async function ProductList() {
 const res = await fetch('https://api.example.com/products');
 const products = await res.json();

 return (
 <div>
 {products.map((product) => (
 <div key={product.id}>
 <h3>{product.name}</h3>
 <p>{new Date(product.createdAt).toLocaleDateString()}</p>
 </div>
 ))}
 </div>
 );
}

// Client Component: يُنفذ في المتصفح ويحتاج إلى جافاسكريبت
'use client';
import { useState } from 'react';

function AddToCartButton({ productId }) {
 const [isLoading, setIsLoading] = useState(false);

 const handleClick = async () => {
 setIsLoading(true);
 await fetch('/api/cart', { method: 'POST', body: JSON.stringify({ productId }) });
 setIsLoading(false);
 };

 return (
 <button {handleClick} disabled={isLoading}>
 {isLoading ? 'جاري الإضافة...' : 'أضف إلى السلة'}
 </button>
 );
}

في هذا المثال، المكون ProductList هو Server Component يُنفذ على السيرفر ويجلب البيانات ويعرضها دون الحاجة إلى أي جافاسكريبت في المتصفح. بينما المكون AddToCartButton هو Client Component يُنفذ في المتصفح ويتعامل مع تفاعل المستخدم. لاحظ كيف أننا استخدمنا 'use client' للإشارة إلى أن هذا المكون يجب أن يُنفذ في المتصفح. هذا هو السر في أداء RSC: تقسيم العمل بين السيرفر والمتصفح بحيث يُنفذ كل جزء في المكان الأنسب له.

كيف يتواصل Server Components مع Client Components؟

أحد أكبر التحديات في RSC هو كيفية تمرير البيانات بين Server Components وClient Components. المشكلة أن Server Components تُنفذ على السيرفر ولا يمكنها استخدام hooks أو state، بينما Client Components تحتاج إلى هذه الميزات للتعامل مع تفاعل المستخدم. الحل هو أن Server Components يمكنها تمرير البيانات إلى Client Components عبر props، لكن هذه البيانات يجب أن تكون قابلة للتسلسل (serializable). هذا يعني أنه لا يمكنك تمرير دوال أو كائنات معقدة، بل فقط أنواع البيانات البسيطة مثل Strings وNumbers وArrays وObjects البسيطة.

// Server Component
async function ProductPage({ productId }) {
 const res = await fetch(`https://api.example.com/products/${productId}`);
 const product = await res.json();

 return (
 <div>
 <h1>{product.name}</h1>
 <p>{product.description}</p>
 {/* تمرير البيانات إلى Client Component عبر props */}
 <AddToCartButton productId={product.id} price={product.price} />
 </div>
 );
}

// Client Component
'use client';
function AddToCartButton({ productId, price }) {
 const [quantity, setQuantity] = useState(1);

 const handleAddToCart = () => {
 // تنفيذ عملية إضافة المنتج إلى السلة
 console.log(`Adding product ${productId} with quantity ${quantity} and price ${price}`);
 };

 return (
 <div>
 <input
 type="number"
 value={quantity}
 {(e) => setQuantity(Number(e.target.value))}
 min="1"
 />
 <button onClick={handleAddToCart}>أضف إلى السلة</button>
 </div>
 );
}

في هذا المثال، المكون ProductPage هو Server Component يجلب بيانات المنتج ويمررها إلى المكون AddToCartButton عبر props. لاحظ أن البيانات التي نمررها هي بسيطة وقابلة للتسلسل. إذا حاولت تمرير دالة أو كائن معقد، ستحصل على خطأ في وقت البناء لأن RSC لا يمكنها التعامل مع هذه الأنواع من البيانات.

الأداء الحقيقي: كيف غيرت RSC قواعد اللعبة؟

عندما انتقلنا إلى RSC في أحد مشاريعنا، رأينا تحسناً مذهلاً في الأداء. الصفحة التي كانت تستغرق ٣ ثوانٍ للتحميل وتستهلك ٣ ميجابايت من جافاسكريبت أصبحت تُحمل في أقل من ٥٠٠ مللي ثانية وتستهلك ٢٠٠ كيلوبايت فقط. السر؟ أننا نقلنا كل العمليات الثقيلة إلى السيرفر، مثل جلب البيانات وتنسيق النصوص، وتركنا للمتصفح فقط التعامل مع التفاعلات البسيطة. هذا أدى إلى تقليل حجم الجافاسكريبت المُرسل إلى المتصفح بنسبة ٩٠٪، وتحسين وقت التحميل الأولي بشكل كبير.

لكن الأداء ليس الفائدة الوحيدة. RSC جعلت الكود أكثر قابلية للصيانة. قبل RSC، كنا نكتب مكونات معقدة تحتوي على منطق جلب البيانات، وتنسيق النصوص، والتعامل مع التفاعلات في نفس الملف. هذا كان يجعل المكونات صعبة الفهم والتعديل. مع RSC، أصبح لدينا فصل واضح بين المكونات التي تُنفذ على السيرفر والمكونات التي تُنفذ في المتصفح. هذا جعل الكود أكثر تنظيماً وأسهل في الصيانة.

• •تقليل حجم الجافاسكريبت المُرسل إلى المتصفح بنسبة تصل إلى ٩٠٪
• •تحسين وقت التحميل الأولي للصفحات بشكل كبير
• •فصل واضح بين منطق السيرفر ومنطق المتصفح
• •تقليل الحمل على المتصفح، مما يؤدي إلى تجربة مستخدم أكثر سلاسة
• •سهولة في جلب البيانات مباشرة من قاعدة البيانات أو خدمات الطرف الثالث دون الحاجة إلى واجهة برمجة تطبيقات (API) وسيطة

مقارنة عملية: قبل RSC وبعد RSC

// قبل RSC: مكون تقليدي
import { useState, useEffect } from 'react';
import axios from 'axios';

function UserProfile({ userId }) {
 const [user, setUser] = useState(null);
 const [loading, setLoading] = useState(true);

 useEffect(() => {
 axios.get(`/api/users/${userId}`).then((response) => {
 setUser(response.data);
 setLoading(false);
 });
 }, [userId]);

 if (loading) return <div>جاري التحميل...</div>;
 if (!user) return <div>المستخدم غير موجود</div>;

 return (
 <div>
 <h1>{user.name}</h1>
 <p>{user.bio}</p>
 </div>
 );
}

// بعد RSC: Server Component
async function UserProfile({ userId }) {
 const res = await fetch(`https://api.example.com/users/${userId}`);
 const user = await res.json();

 if (!user) return <div>المستخدم غير موجود</div>;

 return (
 <div>
 <h1>{user.name}</h1>
 <p>{user.bio}</p>
 </div>
 );
}

في المثال الأول، المكون التقليدي يرسل جافاسكريبت إلى المتصفح لتنفيذ منطق جلب البيانات وعرضها. هذا يؤدي إلى بطء في التحميل الأولي ووميض عند التحميل. في المثال الثاني، المكون يُنفذ بالكامل على السيرفر ويُرجع HTML جاهز للعرض دون الحاجة إلى أي جافاسكريبت في المتصفح. هذا يؤدي إلى تحميل أسرع وتجربة مستخدم أفضل.

الفخاخ الخفية: أين يقع المطورون في أخطاء RSC؟

على الرغم من فوائد RSC، هناك العديد من الفخاخ التي يقع فيها المطورون عند استخدامها. أحد أكبر الأخطاء هو محاولة استخدام hooks أو state داخل Server Components. تذكر أن Server Components تُنفذ على السيرفر ولا يمكنها استخدام أي ميزات تعتمد على المتصفح، مثل hooks أو state. إذا حاولت استخدام useState داخل Server Component، ستحصل على خطأ في وقت البناء.

// ❌ خطأ: استخدام useState داخل Server Component
async function ProductList() {
 const [products, setProducts] = useState([]); // هذا سيسبب خطأ

 const res = await fetch('https://api.example.com/products');
 const data = await res.json();
 setProducts(data); // هذا أيضاً سيسبب خطأ

 return (
 <div>
 {products.map((product) => (
 <div key={product.id}>{product.name}</div>
 ))}
 </div>
 );
}

خطأ آخر شائع هو محاولة تمرير دوال أو كائنات معقدة من Server Components إلى Client Components. تذكر أن البيانات التي تمررها يجب أن تكون قابلة للتسلسل. إذا حاولت تمرير دالة أو كائن يحتوي على دوال، ستحصل على خطأ في وقت البناء. الحل هو تمرير البيانات البسيطة فقط، واستخدام Client Components لتنفيذ المنطق المعقد.

// ❌ خطأ: تمرير دالة من Server Component إلى Client Component
async function ProductPage({ productId }) {
 const res = await fetch(`https://api.example.com/products/${productId}`);
 const product = await res.json();

 return (
 <div>
 <AddToCartButton
 product={product}
 {() => console.log('Product added')} // هذا سيسبب خطأ
 />
 </div>
 );
}

// ✅ صحيح: تمرير بيانات بسيطة فقط
async function ProductPage({ productId }) {
 const res = await fetch(`https://api.example.com/products/${productId}`);
 const product = await res.json();

 return (
 <div>
 <AddToCartButton productId={product.id} price={product.price} />
 </div>
 );
}

أخيراً، أحد أكبر الفخاخ هو محاولة استخدام مكتبات تعتمد على المتصفح داخل Server Components. على سبيل المثال، مكتبات مثل lodash أو date-fns تعتمد على ميزات المتصفح وقد لا تعمل بشكل صحيح داخل Server Components. الحل هو استخدام مكتبات متوافقة مع السيرفر، أو تنفيذ المنطق المطلوب داخل Client Components.

• •عدم استخدام hooks أو state داخل Server Components
• •عدم تمرير دوال أو كائنات معقدة من Server Components إلى Client Components
• •عدم استخدام مكتبات تعتمد على المتصفح داخل Server Components
• •التأكد من أن البيانات التي تمررها قابلة للتسلسل
• •فصل واضح بين منطق السيرفر ومنطق المتصفح لتجنب التعقيد

متى يجب استخدام RSC ومتى يجب تجنبها؟

RSC ليست الحل السحري لكل المشاكل. هناك حالات يجب فيها استخدام Client Components التقليدية، وحالات أخرى تكون RSC هي الخيار الأمثل. القاعدة الأساسية هي: إذا كان المكون يحتاج إلى تفاعل المستخدم، مثل الأزرار والنماذج، فاستخدم Client Components. إذا كان المكون يعرض بيانات ثابتة أو يجري عمليات ثقيلة مثل جلب البيانات، فاستخدم Server Components.

على سبيل المثال، في تطبيق التجارة الإلكترونية، يمكنك استخدام Server Components لعرض قائمة المنتجات وصفحة تفاصيل المنتج، لأنها تحتاج إلى جلب بيانات وعرضها دون تفاعل معقد. بينما تستخدم Client Components للأزرار مثل "أضف إلى السلة" و"الشراء الآن"، لأنها تحتاج إلى تفاعل المستخدم. هذا الفصل بين المكونات يؤدي إلى أداء أفضل وتجربة مستخدم أكثر سلاسة.

• •**استخدم Server Components عندما:**
• •- تحتاج إلى جلب بيانات من قاعدة البيانات أو خدمات الطرف الثالث
• •- تريد عرض بيانات ثابتة دون تفاعل المستخدم
• •- تريد تقليل حجم الجافاسكريبت المُرسل إلى المتصفح
• •- تريد تحسين وقت التحميل الأولي للصفحات
• •- تحتاج إلى تنفيذ عمليات ثقيلة مثل تنسيق النصوص أو العمليات الحسابية البسيطة

• •**استخدم Client Components عندما:**
• •- تحتاج إلى تفاعل المستخدم مثل الأزرار والنماذج
• •- تريد استخدام hooks أو state لإدارة الحالة المحلية
• •- تحتاج إلى الوصول إلى ميزات المتصفح مثل localStorage أو geolocation
• •- تريد استخدام مكتبات تعتمد على المتصفح مثل الرسوم البيانية أو مكتبات واجهة المستخدم المعقدة

خلاصة المهندس: نصيحة واحدة ستغير طريقة تفكيرك في RSC

إذا كنت تريد أن تستفيد حقاً من React Server Components، فتوقف عن التفكير فيها كتقنية جديدة يجب تعلمها، وابدأ في التفكير فيها كطريقة لإعادة توزيع العمل بين السيرفر والمتصفح. السر ليس في تحويل كل مكوناتك إلى Server Components، بل في تحديد أي الأجزاء من تطبيقك يمكن تنفيذها على السيرفر دون الحاجة إلى جافاسكريبت في المتصفح. ابدأ بمكونات بسيطة مثل عرض البيانات، ثم انتقل تدريجياً إلى المكونات الأكثر تعقيداً.

نصيحة ذهبية: في كل مرة تكتب مكوناً جديداً، اسأل نفسك هذا السؤال: "هل هذا المكون يحتاج إلى تفاعل المستخدم؟" إذا كانت الإجابة لا، فاجعله Server Component. إذا كانت الإجابة نعم، فاجعله Client Component. هذا التفكير البسيط سيقودك إلى بناء تطبيقات أسرع وأكثر كفاءة دون تعقيد إضافي. ولا تنسَ أن RSC ليست بديلاً للـ Server-Side Rendering (SSR) أو Static Site Generation (SSG)، بل هي أداة إضافية في صندوق أدواتك يمكنك استخدامها لتحسين أداء تطبيقك.

React Server Components ليست مجرد ميزة جديدة في الريأكت، بل هي تحول في طريقة تفكيرنا في بناء تطبيقات الويب. إنها تجعلنا نعيد النظر في كيفية توزيع العمل بين السيرفر والمتصفح، وكيف يمكننا بناء تطبيقات أسرع وأكثر كفاءة دون التضحية بتجربة المستخدم.

— مهندس برمجيات سنيور في نوفيل