وصف المنتج واحد للجميع، لكن عنوان التسليم المعروض للمستخدم المسجل قد يختلف. هل يجب تأخير الوصف لأن جلب العنوان بطيء؟ نستخدم صفحة افتراضية لبيع الكتب لفهم فصل المحتوى المشترك عن منطقة المستخدم. الميزة هي جزر خادم Astro، ووظيفتها مختلفة عن جزر العميل التي تشغّل الأزرار في المتصفح.
1. فصل المستند الأول عن المنطقة اللاحقة
تشرح وثائق جزر الخادم الرسمية تأخير تصيير مكون معين على الخادم وجلبه بطلب منفصل. يتضمن HTML الأول المحتوى الأساسي وما يظهر أثناء الانتظار ثم تُستبدل المنطقة بالاستجابة. يحتاج ذلك محولاً يعالج الطلب في الخادم.
في صفحة الكتاب نترك العنوان والمؤلف والتعريف مشتركاً ونختار ملخص العنوان فقط مرشحاً. يستطيع الزائر قراءة التعريف بالكتاب أثناء انتظار عنوان التسليم. أما إذا لزم المجموع لفهم زر الدفع، فيجب تصميم علاقة السعر بالفعل أيضاً. تقسيم العناصر لصناديق صغيرة ليس وحده فصلاً وظيفياً كاملاً.
يتحدد نجاح التصميم بما يعرض أولاً. تأخير معظم الصفحة مع محتوى فارغ تقريباً يترك الزائر ينتظر مؤشرات كثيرة. صنّف أولاً أسئلة الشاشة الأولى والمعلومات التي يمكن تأخيرها. الجزر تنقل موضع الانتظار، ولا تسرع قاعدة البيانات تلقائياً.
2. تصميم fallback جزءاً من الشاشة المكتملة
المثال الصغير التالي يبين الاستخدام بافتراض تنفيذ UserDelivery والمحول منفصلين.
---
import UserDelivery from '../components/UserDelivery.astro';
---
<UserDelivery server:defer>
<p slot="fallback">جارٍ التحقق من عنوان التسليم.</p>
</UserDelivery>ليس fallback زينة مؤقتة بل محتوى أول يقرؤه الزائر. احجز مساحة قريبة من حجم بطاقة العنوان وفسر المنتظر. عرض «التسليم متاح» قبل المعلومات قد يتعارض مع الجواب. ميّز بصرياً المجهول عن المؤكد.
قد يحتاج غير المسجل رسالة «سجّل الدخول لرؤية عنوانك المحفوظ». بطء الشبكة وعدم الدخول حالتان مختلفتان. تحديد النص ومسار الانتقال لكل واحدة يمنع بقاء جملة تجريبية في الإنتاج.
3. إبقاء حدود البيانات صغيرة
مرر فقط القيم اللازمة للعرض والجلب. إرسال تاريخ الطلبات كله لإظهار اسم واحد فرصة لتقليل الاعتماد أولاً. بعض القيم عامة وأخرى لا تُجلب إلا بعد التحقق. افحص مسار النقل ونطاق العرض في القائمة نفسها.
طلب جزيرة الخادم في سياق تنفيذ منفصل. إن احتاج المنطق عنوان الصفحة، مرر المسار المطلوب صراحة من الأصل. افتراض URL الطلب داخل الجزيرة عنوانَ المنتج قد يفسد التوصيات والعودة. افحص الطلب الحقيقي بأدوات المطور عند التنفيذ.
في مثال رقم الكتاب وهوية المستخدم، استخدم الرقم للتوصيات العامة وتعامل مع هوية المستخدم وفق التحقق بالخادم. النقل المشفر لا يحل محل الصلاحيات. وثّق موضع استقبال الإدخال منفصلاً عن موضع السماح النهائي.
4. ضبط التخزين بحسب جمهور الاستجابة
يصعب تطبيق سياسة واحدة على تعريف كتاب عام وعنوان خاص. يشرح دليل MDN للتخزين HTTP العام والخاص. احكم أولاً لمن يجوز رؤية الاستجابة، لا هل البيانات متماثلة فقط.
افتح الصفحة بحسابي اختبار وتأكد ألا يظهر عنوان الأول للثاني. افحص العودة والتحديث بعد الخروج أيضاً. الاختبار لنتيجة تعاون خادم التخزين والمتصفح والتحقق بالتطبيق؛ لا تكفي قراءة ملف المكون للحكم بالأمان.
الأجزاء المشتركة كتوصية كتاب تحتاج تحديثاً أيضاً. قرر قبول القديم مؤقتاً أو استبداله فور تعديل المدير. اكتب الهدف والمكان والقدم المقبول وشرط الإبطال بدلاً من «تشغيل التخزين»، لتسهل مراجعة الآخرين.
5. تجربة البطء والفشل أولاً
لا تقيّم بفتح واحد في اتصال سليم. أخّر طلب العنوان وأفشله وغيّر الدخول وافحص الحالات. هل يُقرأ الأساس، وهل تدفع منطقة التحميل الزر التالي باستمرار، وهل تبقى عملية تعتمد على المعلومة الفاشلة ممكنة؟
| حالة الاختبار | ما ينبغي أن يفهمه الزائر |
|---|---|
| بطء جلب العنوان | ما المنتظر وهل يمكن قراءة غيره؟ |
| غياب التحقق | هل يظهر توجيه الدخول والمحتوى المشترك؟ |
| فشل الجلب | هل يجد مسار تعافٍ بدلاً من الفراغ؟ |
| تبديل الحساب | هل بقيت معلومات السابق؟ |
إن انتظرت جزر بعضها فراجع الفصل. جلب عنوان التسليم ثم الاستعلام عن تكلفة الشحن ثم عرض إرشادات الدفع قد يصنع سلسلة طلبات انتظار. قد يفيد جمعها بعمل خادم واحد أو جلبها عندما يطلب المستخدم. كثرة الأجزاء ليست بنية جيدة تلقائياً.
6. مقارنة المكاسب بشروط متساوية
سجل ظهور المحتوى واكتمال العنوان وإتاحة التحكم والخطأ منفصلة. ظهور المستند سريعاً مع قفز البطاقة أو تأخر الدفع قد يغير التجربة باتجاه آخر. لا تكتب متوسطاً واحداً فقط؛ سجل ما انتظرته الحالات البطيئة.
السؤال المحدد أفضل لاختيار المرشح: «هل يمكن قراءة التعريف بالكتاب أولاً حتى إن تأخرت هذه المعلومة؟» أنفع من «هل الموقع ثابت؟». تحقق من بيئة النشر مع دليل التصيير عند الطلب وابدأ بمنطقة شخصية صغيرة ثم اختبر الفشل الحقيقي.