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