العرض الثابت مع دعم وضع التحرير

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

بنية المسارين المزدوجة

نستخدم مسارين للمحتوى نفسه:

app/
├── [...slug]/page.tsx          # الإنتاج: force-static (سريع)
└── preview/[...slug]/page.tsx  # وضع التحرير: force-dynamic (يقرأ searchParams)

تقوم وسيطة الوكيل بإعادة كتابة طلبات وضع التحرير بشكل شفاف:

طلبات المستخدم: /en/headless/quickstart?edit_mode=true
       ↓
يكتشف الوكيل ?edit_mode=true
       ↓
إعادة كتابة داخلية إلى: /preview/en/headless/quickstart?edit_mode=true
       ↓
يقوم المسار الديناميكي بالتصيير مع أغلفة التحرير

لا يرى المستخدم أبدًا /preview في عنوان URL الخاص به - إنها إعادة كتابة داخلية.

كيف يعمل

مسار الإنتاج (الافتراضي)

// app/[...slug]/page.tsx
export const dynamic = 'force-static';
export const revalidate = 60;

export default async function Page({ params }) {
  // لا توجد searchParams - الصفحة ثابتة بالكامل
  return

• تُنشأ الصفحات مسبقًا أثناء عملية البناء
• تُقدَّم على الفور من ذاكرة التخزين المؤقت للحافة في CDN
• يُعاد التحقق منها كل 60 ثانية (ISR) كشبكة أمان

مسار وضع التحرير

// app/preview/[...slug]/page.tsx
export const dynamic = 'force-dynamic';

export default async function PreviewPage({ params, searchParams }) {
  // searchParams متاحة - يمكنها اكتشاف edit_mode
  return <ParametricRoutePage params={params

• يُعاد التصيير مع كل طلب
• يمكنه قراءة ?edit_mode=true من عنوان URL
• يصيّر مع أغلفة قابلة للتحرير من نظام إدارة المحتوى ومخططات الكتل

إعادة كتابة الوكيل

// src/proxy.ts
export const proxy = async (request: NextRequest) => {
  const { pathname, searchParams } = request.nextUrl;

  const editMode = searchParams.get('edit_mode');

مقارنة الأداء

فهم ISR (إعادة التوليد الثابت التزايدي)

إعداد revalidate = 60 يمكّن ISR. هذا لا يعني أن الصفحات يعاد احتسابها كل 60 ثانية.

يستخدم ISR نمط stale-while-revalidate:

وصول طلب:
  → هل الصفحة المخزنة مؤقتًا أحدث من 60 ثانية؟ → قدّم من الذاكرة المؤقتة (فوري)
  → هل الصفحة المخزنة مؤقتًا أقدم من 60 ثانية؟ → قدّم النسخة القديمة من الذاكرة المؤقتة (فوري)
                                + إعادة التحقق في الخلفية للطلب التالي

لا توجد طلبات = لا إعادة احتساب. إطلاقًا.

مثال:

• تم تخزين الصفحة مؤقتًا في الساعة 10:00 صباحًا
• لا يوجد زوار حتى الساعة 3:00 مساءً
• يحصل أول زائر في الساعة 3:00 مساءً على النسخة القديمة من الذاكرة المؤقتة فورًا
• يحدث تحديث في الخلفية، ويحصل الزائر التالي على محتوى حديث

نافذة الستين ثانية عبارة عن شبكة أمان. من الناحية المثالية، سنستخدم إعادة التحقق عند الطلب عبر webhooks عند تغير محتوى نظام إدارة المحتوى.

متى نستخدم كل مسار

لماذا لا نستخدم التصيير الديناميكي فحسب؟

النهج البسيط (من دون force-static، ومن دون مسار معاينة) يعمل ولكنه بطيء:

// نهج بسيط - يعمل ولكن يستغرق حوالي 1-2 ثانية لكل طلب
export default async function Page({ params, searchParams }) {
  return <ParametricRoutePage params={params} searchParams={searchParams} />;
}

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

• تشغيل بارد في كل صفحة
• لا استفادة من التخزين المؤقت على حافة CDN
• أزمنة تحميل من 1-2 ثانية مقابل أجزاء من الثانية

تمنحنا بنية المسارين المزدوجة أفضل ما في العالمين: سرعة ثابتة للقراء، ووظائف ديناميكية للمحررين.