التصيير (Rendering)

التحويل الذي تقوم به من الكود الذي تكتبه إلى واجهات المستخدم يُعرف بالتصيير. تسمح لك React وNext.js بإنشاء تطبيقات ويب هجينة حيث يمكن تصيير أجزاء من الكود على الخادم أو العميل. سيساعدك هذا القسم على فهم الفروق بين بيئات التصيير هذه واستراتيجياتها وبيئات التشغيل.

الأساسيات

للبدء، من المفيد أن تتعرف على ثلاثة مفاهيم أساسية في الويب:

• بيئات التصيير التي يمكن تنفيذ كود التطبيق فيها: الخادم والعميل.
• دورة الطلب-الاستجابة التي تبدأ عندما يزور المستخدم أو يتفاعل مع تطبيقك.
• حدود الشبكة التي تفصل بين كود الخادم والعميل.

بيئات التصيير

هناك بيئتان يمكن فيهما تصيير تطبيقات الويب: العميل والخادم.

• العميل (Client) يشير إلى المتصفح على جهاز المستخدم الذي يرسل طلبًا إلى خادم للحصول على كود التطبيق. ثم يحول الاستجابة من الخادم إلى واجهة مستخدم.
• الخادم (Server) يشير إلى الكمبيوتر في مركز البيانات الذي يخزن كود التطبيق الخاص بك، ويتلقى الطلبات من العميل، ويرسل استجابة مناسبة.

تاريخيًا، كان على المطورين استخدام لغات مختلفة (مثل JavaScript، PHP) وأُطر عمل عند كتابة الكود للخادم والعميل. مع React، يمكن للمطورين استخدام نفس اللغة (JavaScript) ونفس إطار العمل (مثل Next.js أو إطار العمل الذي تختاره). هذه المرونة تتيح لك كتابة الكود بسلاسة لكلا البيئتين دون الحاجة إلى التبديل بين السياقات.

ومع ذلك، لكل بيئة مجموعة خاصة من الإمكانيات والقيود. لذلك، فإن الكود الذي تكتبه للخادم والعميل ليس دائمًا متطابقًا. هناك عمليات معينة (مثل جلب البيانات أو إدارة حالة المستخدم) تكون أكثر ملاءمة لبيئة عن الأخرى.

فهم هذه الفروق هو مفتاح الاستخدام الفعال لـ React وNext.js. سنغطي الفروق وحالات الاستخدام بمزيد من التفصيل في صفحات مكونات الخادم ومكونات العميل، لكن حاليًا دعونا نواصل البناء على أساسنا.

دورة الطلب-الاستجابة

بشكل عام، تتبع جميع مواقع الويب نفس دورة الطلب-الاستجابة:

1. إجراء المستخدم: يتفاعل المستخدم مع تطبيق الويب. يمكن أن يكون هذا النقر على رابط، أو إرسال نموذج، أو كتابة عنوان URL مباشرة في شريط عنوان المتصفح.
2. طلب HTTP: يرسل العميل طلب HTTP إلى الخادم يحتوي على المعلومات الضرورية حول الموارد المطلوبة، والطريقة المستخدمة (مثل GET، POST)، وبيانات إضافية إذا لزم الأمر.
3. الخادم: يعالج الخادم الطلب ويستجيب بالموارد المناسبة. قد تتضمن هذه العملية عدة خطوات مثل التوجيه، جلب البيانات، إلخ.
4. استجابة HTTP: بعد معالجة الطلب، يرسل الخادم استجابة HTTP إلى العميل. تحتوي هذه الاستجابة على رمز حالة (يخبر العميل ما إذا كان الطلب ناجحًا أم لا) والموارد المطلوبة (مثل HTML، CSS، JavaScript، موارد ثابتة، إلخ).
5. العميل: يحلل العميل الموارد لعرض واجهة المستخدم.
6. إجراء المستخدم: بمجرد عرض واجهة المستخدم، يمكن للمستخدم التفاعل معها، وتبدأ الدورة مرة أخرى.

جزء كبير من بناء تطبيق ويب هجين هو تحديد كيفية تقسيم العمل في الدورة، وأين يتم وضع حدود الشبكة.

حدود الشبكة

في تطوير الويب، حدود الشبكة (Network Boundary) هي خط مفاهيمي يفصل بين البيئات المختلفة. على سبيل المثال، العميل والخادم، أو الخادم ومخزن البيانات.

في React، يمكنك اختيار مكان وضع حدود الشبكة بين العميل والخادم حيثما كان ذلك أكثر منطقية.

خلف الكواليس، يتم تقسيم العمل إلى جزأين: رسم بياني لوحدة العميل ورسم بياني لوحدة الخادم. يحتوي رسم وحدة الخادم على جميع المكونات التي يتم تصييرها على الخادم، ويحتوي رسم وحدة العميل على جميع المكونات التي يتم تصييرها على العميل.

قد يكون من المفيد التفكير في رسومات الوحدات كتمثيل مرئي لكيفية اعتماد الملفات في تطبيقك على بعضها البعض.

يمكنك استخدام اصطلاح React "use client" لتحديد الحدود. هناك أيضًا اصطلاح "use server"، الذي يخبر React بتنفيذ بعض الأعمال الحسابية على الخادم أثناء وجوده على العميل.

بناء تطبيقات هجينة

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

إذا كنت بحاجة إلى الوصول إلى الخادم من العميل، فترسل طلبًا جديدًا إلى الخادم بدلاً من إعادة استخدام نفس الطلب. وهذا يسهل فهم مكان تصيير المكونات وأين يتم وضع حدود الشبكة.

عمليًا، يشجع هذا النموذج المطورين على التفكير فيما يريدون تنفيذه على الخادم أولاً، قبل إرسال النتيجة إلى العميل وجعل التطبيق تفاعليًا.

سيصبح هذا المفهوم أوضح عندما ننظر إلى كيفية تداخل مكونات العميل والخادم في نفس شجرة المكونات.