Server Components في Next.js ببساطة: عبدالله عبدالرحيم بن سنكر يجاوب

تفتح مشروع Next.js جديد، وتكتب زراً عادياً فيه onClick، فيطلع لك خطأ يقول إن هذا ما ينفع في Server Component. تحط «use client» في أعلى الملف فيختفي الخطأ، وتكمل. بعد شهر تلقى نص المشروع عليه نفس السطر، ولا تدري وش خسرت. عبدالله عبدالرحيم بن سنكر يبني المواقع بـ Next.js و TypeScript، وهذي الأسئلة اللي تتكرر عليه عن مكونات الخادم، بإجابات مباشرة بدون تنظير.

وش هي Server Components أصلاً؟

في App Router، أي مكوّن تكتبه هو مكوّن خادم افتراضياً. يعني يشتغل على الخادم، وقت البناء أو وقت الطلب، والمتصفح يستلم النتيجة جاهزة: HTML للعرض الأول، وبيانات خفيفة تصف شكل الواجهة. أما كود المكوّن نفسه، والمكتبات اللي استوردها، فما تنزل للمتصفح أبداً. لو استخدمت مكتبة ثقيلة لتنسيق التواريخ أو تحويل Markdown داخل مكوّن خادم، الزائر ما يدفع ثمنها من سرعة جواله.

ووش تكسب فعلاً؟ ثلاث مكاسب عملية. الأولى جافاسكربت أقل في المتصفح، وهذا يعني صفحة تصير تفاعلية أسرع على الجوالات المتوسطة. الثانية إن المكوّن يقدر يكون async ويجيب بياناته بنفسه: استعلام قاعدة بيانات أو طلب لخدمة خارجية مباشرة داخل المكوّن، بدون ما تبني مسار API وسيط بس عشان تنادي عليه. الثالثة الأمان: المفاتيح السرية وروابط قواعد البيانات تبقى على الخادم. أي خدمة ذكاء اصطناعي تنادي عليها بمفتاح مدفوع، مثل خدمات النماذج اللي يمر عليها شات azhal.io عبر OpenRouter، مكان مفتاحها الخادم، مو كود يقدر أي زائر يفتحه من أدوات المطوّر.

طيب ومتى أحتاج Client Component؟

لما يحتاج المكوّن شي ما يوجد إلا في المتصفح. القائمة واضحة:

• حالة تتغير مع تفاعل المستخدم عبر useState أو useReducer.
• تأثيرات تشتغل بعد العرض عبر useEffect، مثل الاشتراك في حدث أو مؤقت.
• معالجات أحداث مثل onClick و onChange و onSubmit المكتوبة كدوال في المتصفح.
• واجهات المتصفح نفسها: window و localStorage والموقع الجغرافي والحافظة.
• مكتبات مبنية على هذي الأشياء، مثل بعض مكتبات الرسوم البيانية والخرائط والحركة.

وسطر «use client» مو مجرد إذن، هو حدّ فاصل. الملف اللي يحمله، وكل ملف يستورده هذا الملف، يدخل في حزمة الجافاسكربت اللي تنزل للمتصفح. عشان كذا مكانه مهم جداً.

كيف أقسّم الصفحة صح؟

القاعدة: ادفع «use client» لأطراف الشجرة. صفحة منتج فيها صور ووصف ومواصفات وتقييمات وزر «أضف للسلة». كل هذا يبقى مكوّن خادم، إلا الزر وعدّاد الكمية، يكونون مكوّناً صغيراً للعميل. بدل ما تخلي الصفحة كلها عميلاً عشان زر واحد.

ولو احتجت مكوّن عميل يغلّف محتوى خادم، مثل نافذة منبثقة أو تبويبات، مرّر محتوى الخادم له كـ children. مكوّن العميل يتحكم في الفتح والإغلاق، والمحتوى داخله يبقى مرسوماً على الخادم. وانتبه إن أي خصائص تمرّرها من مكوّن خادم لمكوّن عميل لازم تكون قابلة للتسلسل: نصوص وأرقام وكائنات بسيطة ومصفوفات، مو دوال عادية ولا كائنات معقدة.

هل التشغيل على الخادم يعني صفحة أبطأ؟

مو بالضرورة. الصفحات اللي ما تتغير لكل زائر ممكن تنبني مسبقاً وقت النشر وتنخدم كملف جاهز، وهذا أسرع شي ممكن. والصفحات الديناميكية تقدر تستفيد من البث: ملف loading.tsx أو حدود Suspense تخلّي الهيكل يظهر فوراً، والجزء البطيء، مثل قائمة توصيات من خدمة بطيئة، يكمّل لما تجهز بياناته بدون ما يأخّر باقي الصفحة. أما سياسات التخزين المؤقت للطلبات فتغيرت بين إصدارات Next.js أكثر من مرة، فلا تعتمد على ذاكرتك أو على مقالة قديمة، اقرأ وثائق الإصدار اللي تستخدمه وحدد سلوك كل طلب بوضوح.

ووين تدخل Server Actions في القصة؟

هي دوال تكتب في أولها «use server»، وتقدر تربطها بنموذج HTML أو تناديها من مكوّن عميل، وهي تشتغل على الخادم. مريحة جداً: نموذج تواصل يحفظ في القاعدة بدون ما تكتب مسار API. لكن خلّها في بالك على حقيقتها: كل Server Action هي نقطة نهاية عامة يقدر أي أحد يرسل لها طلباً، حتى لو كان الزر مخفياً في الواجهة. فتحقق داخلها من هوية المستخدم وصلاحيته، وتحقق من كل مدخل يجيها، بنفس الصرامة اللي تتعامل فيها مع أي API.

وش الأخطاء اللي تتكرر؟

• وضع «use client» في ملف layout الرئيسي عشان مزوّد سياق واحد، فيتحول الموقع كله لمكونات عميل. الحل: مكوّن Providers صغير للعميل، والـ layout يبقى خادماً ويمرر children.
• استيراد ملف فيه اتصال قاعدة البيانات داخل مكوّن عميل بالغلط. حزمة server-only تخلّي البناء يفشل لو صار هذا، بدل ما يتسرب كود الخادم.
• توقع إن متغيرات البيئة تشتغل في المتصفح. اللي يبدأ بـ NEXT_PUBLIC_ بس يوصل للمتصفح، وهذا يعني إن أي شي فيه هذا البادئ يشوفه الكل، فلا تحط فيه سراً.
• مكوّن خادم يطلب مسار API من نفس التطبيق عبر fetch، بينما يقدر ينادي الدالة نفسها مباشرة ويوفّر رحلة كاملة عبر الشبكة.
• استخدام window أو localStorage في أول عرض لمكوّن عميل، مع إن مكوّن العميل نفسه ينرسم على الخادم أول مرة. مكان هذا الكود useEffect.

وإذا تسأل كيف تبدأ بدون ما تتلخبط: ابدأ كل مكوّن كمكوّن خادم، ولا تضيف «use client» إلا لما يطلب منك الإطار هذا لسبب تفهمه. ولما تضيفه، اسأل: هل أقدر أعزل الجزء التفاعلي في ملف أصغر؟ هذا السؤال وحده يحل أغلب المشاكل. وموقع azhal.io نفسه مبني بـ Next.js، والمنطق اللي يمشي عليه عبدالله عبدالرحيم بن سنكر الكندي في منصة أزهل الرقمية بسيط: المحتوى يُرسم على الخادم، والتفاعل يُضاف بالقطّارة، في المكان اللي يحتاجه بالضبط.