ما هي مكونات الخادم فعلياً
تعلم كيفية التفكير في مكونات الخادم كحدود عرض تفصل بين عمل البيانات وعمل التفاعل، مما يغير طريقة تفكير React .
في تطبيقات React التقليدية، يُطلب من المتصفح القيام بالكثير من المهام في وقت مبكر جدًا. حتى عندما يكون خادم قد حصل على البيانات، يبقى التدفق المعتاد كما هو: إرسال واجهة المستخدم كـ JavaScript، تشغيلها على عميل، عرض واجهة أولية، ثم جلب البيانات مرة أخرى وعرضها للمرة الثانية. إلى حين وصول البيانات، غالبًا ما تعود واجهة المستخدم إلى استخدام عناصر نائبة أو مؤشرات تحميل أو شاشات جزئية. بمجرد اكتمال البيانات، يقوم React بالعرض مرة أخرى، ثم يُجري عملية التوفيق، ثم يُضيف عناصر التفاعل فوق الترميز الذي كان من الممكن أن يُنتجه خادم منذ البداية.
يصبح هذا الأمر مكلفًا مع توسع نطاق التطبيقات. إذ يتحمل عميل مسؤولية إدارة البيانات، والتخزين المؤقت، وتنسيق الحالة، ومنطق العرض، حتى بالنسبة لواجهة المستخدم غير التفاعلية. وتتضخم حزم البيانات لأن كل مكون، بما في ذلك المكونات للقراءة فقط، يجب شحنه وتحليله وحفظه في الذاكرة. ولا يمكن للمنطق الحساس أو الخاص بالخادم فقط أن يتواجد بأمان في نفس مكان العرض، لذا يتم تكراره أو توجيهه إلى خادم وسيط أو تقسيمه إلى واجهات برمجة تطبيقات إضافية. ويتحول تحسين الأداء إلى محاولة لإخفاء زمن الاستجابة من خلال العرض من جانب الخادم، والتخزين المؤقت، والجلب المسبق، وتحميل الحالات، بدلاً من التخلص من العمل غير الضروري عميل .
يُقدّم React 19 مكونات الخادم لمعالجة هذا التباين. لا تكمن المشكلة الأساسية في قدرة خادم على عرض صفحات HTML بشكل أسرع، بل في أن العديد من قرارات العرض يجب أن تكون قريبة من البيانات، ولا ينبغي أن تتطلب تنفيذها من جانب العميل. تسمح مكونات الخادم بتشغيل أجزاء من شجرة العرض حيث يكون الوصول إلى البيانات سهلاً وآمناً، بينما يركز المتصفح على ما يُجيده: التفاعل.
يوضح الرسم التخطيطي أعلاه شجرة مكونات React من الأعلى إلى الأسفل. يُنفَّذ الجزء العلوي على خادم، حيث تصل المكونات بشكل متزامن إلى قواعد البيانات أو الخدمات وتُنتج إخراج مُعالَجة. تتدفق هذه إخراج إلى أسفل نحو حدٍّ يُشير إلى الانتقال إلى عميل. أسفل هذا الحد، تُضيف مكونات العميل الحالة، ومعالجات الأحداث، والسلوك التفاعلي. لا يعبر كود مكونات جانب الخادم هذا الحد أبدًا؛ بل تعبره فقط النتائج المُعالَجة.
مكونات الخادم كعقد مشاركة مختلف
لا ينبغي فهم مكونات الخادم على أنها مكونات تعمل ببساطة على خادم بدلاً من عميل. إنها مكونات لا تُدمج أبدًا في البرنامج التنفيذي للعميل. يتم عرضها في بيئة يكون فيها الوصول إلى البيانات مباشرًا، والبيانات السرية آمنة، والعمليات الحسابية المعقدة مقبولة. لا يكون إخراج عبارة عن كود تفاعلي، بل هو وصف مُسلسل لواجهة المستخدم يمكن لـ React دمجه في شجرة العرض الكلية.
ما هي واجهة المستخدم التسلسلية؟
يمكن اعتبارها بمثابة تدفق بيانات متخصص يشبه JSON، ويُطلق عليه غالبًا اسم حمولة RSC . تحتوي هذه الحمولة على تعليمات بنية HTML النهائية، بالإضافة إلى المواقع التي تحتاج فيها مكونات العميل إلى "تحديث" (تنشيط). يسمح هذا React بتحديث DOM على عميل دون أن يحتاج عميل إلى تنزيل منطق مكونات الخادم.
يُغيّر هذا مفهوم العرض في React. تقليديًا، يُشارك كل مُكوّن ضمنيًا في وقت تشغيل عميل : يجب تجميعه وتحليله وتهيئته وحفظه في الذاكرة. تُخالف مُكوّنات الخادم هذا الافتراض. فهي تُشارك في العرض، ولكن ليس في دورة حياة عميل . يُمكنها جلب البيانات مُباشرةً، وتكوين مُكوّنات خادم أخرى، وإعداد واجهة المستخدم دون زيادة تكلفة JavaScript للمُتصفح.
لا تحل مكونات الخادم محل مكونات العميل. يتم دمج بنية الشجرة عمدًا: حيث تتدفق المناطق التي يعرضها الخادم كنتائج، ويتم تمييز الأجزاء التفاعلية بشكل صريح (على سبيل المثال، باستخدام"use client" ) ويتم ترطيبها في المتصفح. الحدود معمارية وليست عرضية: يقوم العمل من جانب الخادم بحل البيانات والبنية أولاً، ويتلقى عميل شجرة مكتملة جزئيًا بدلاً من إعادة بناء كل شيء بعد الترطيب.
الفكرة مفتاح هي أن React لا تُنسق فقط وقت عرض العناصر، بل تُنسق أيضًا مكان عرضها. تسمح مكونات الخادم React بنقل العمليات غير التفاعلية خارج المتصفح دون الإخلال بنموذج المكونات. الآن وقد فهمنا سبب وجود مكونات الخادم، سنُطبّق هذا النموذج الذهني في مثال عملي. ...