الدليل الشامل لـ Next.js 15 App Router — أفضل ممارسات Server Components

يمثل App Router في Next.js 15 نموذجًا جديدًا مبنيًا حول React Server Components. إليك مجموعة من أفضل الممارسات التي تم التحقق منها في بيئات الإنتاج حتى عام 2026.

1. هيكل نظام الملفات

app/
  layout.tsx           # التخطيط الجذري (مطلوب)
  page.tsx             # الصفحة الرئيسية /
  loading.tsx          # واجهة التحميل
  error.tsx            # حد الخطأ
  not-found.tsx        # 404
  (marketing)/         # مجموعة مسار (لا تؤثر على URL)
    page.tsx
  blog/
    [slug]/
      page.tsx         # /blog/xxx
  api/
    route.ts           # نقطة نهاية REST

مجموعات المسار (group): تُستخدم لمشاركة التخطيطات دون التأثير على هيكل URL.

2. مكونات الخادم مقابل مكونات العميل

الخادم هو الافتراضي. يجب على المكون أن يعلن صراحةً "use client" ليُعامل كمكون عميل.

// مكون الخادم (افتراضي)
async function Page() {
  const user = await fetchUser()  // يتم الجلب مباشرة على الخادم
  return <ProfileCard user={user} />
}

// مكون العميل
"use client"
function InteractiveButton() {
  const [count, setCount] = useState(0)
  return <button onClick={() => setCount(count + 1)}>{count}</button>
}

مبادئ الحدود

• ضع "use client" عند أدنى ورقة في شجرة المكونات.
• احتفظ بالمكونات العليا كمكونات خادم.
• يجب أن تكون القيم المُمررة كـ props قابلة للتسلسل (أنواع متوافقة مع JSON فقط).

3. جلب البيانات

// الجلب المتوازي
async function Page({ params }) {
  const [user, posts] = await Promise.all([
    fetchUser(params.id),
    fetchPosts(params.id),
  ])
  return <Dashboard user={user} posts={posts} />
}

التخزين المؤقت التلقائي لـ fetch:

• fetch(url) — يستخدم ذاكرة التخزين المؤقت الافتراضية
• fetch(url, { cache: "no-store" }) — يعيد الجلب عند كل طلب
• fetch(url, { next: { revalidate: 60 } }) — ISR، يُعاد التحقق كل 60 ثانية

4. Suspense + Streaming

import { Suspense } from "react"

export default function Page() {
  return (
    <>
      <FastSection />
      <Suspense fallback={<Skeleton />}>
        <SlowSection />
      </Suspense>
    </>
  )
}

async function SlowSection() {
  await new Promise(r => setTimeout(r, 2000))
  return <div>تم</div>
}

يتم بث القسم البطيء فقط، مما يتيح تحسينًا فوريًا لـ TTFB.

5. إجراءات الخادم (Server Actions)

// app/actions.ts
"use server"
export async function createPost(formData: FormData) {
  const title = formData.get("title") as string
  await db.insert(posts).values({ title })
  revalidatePath("/blog")
}

// app/blog/new/page.tsx
import { createPost } from "../actions"
export default function NewPost() {
  return <form action={createPost}>...</form>
}

يمكن استدعاء منطق الخادم مباشرةً دون واجهة برمجة REST، وتتم معالجة حماية CSRF تلقائيًا.

6. حدود الأخطاء

// app/blog/error.tsx
"use client"
export default function Error({ error, reset }) {
  return (
    <div>
      <p>{error.message}</p>
      <button onClick={reset}>إعادة المحاولة</button>
    </div>
  )
}

تسمح حدود الأخطاء على مستوى المقطع ببقاء باقي الصفحة تعمل بشكل طبيعي حتى عند حدوث خطأ في جزء واحد.

7. البيانات الوصفية وتحسين SEO

export const metadata = {
  title: "صفحتي",
  description: "...",
}

// أو تعيينها ديناميكيًا
export async function generateMetadata({ params }) {
  const post = await fetchPost(params.slug)
  return { title: post.title }
}

أفضل 10 ممارسات

1. 1الخادم افتراضيًا: استخدم "use client" فقط عند الضرورة القصوى
2. 2جلب البيانات من أعلى مستوى ممكن: تجنب تمرير الخصائص عبر طبقات متعددة
3. 3استخدام Suspense بفاعلية: تعظيم TTFB بالبث
4. 4fetch + revalidate: تخزين مؤقت تلقائي بدون Redis
5. 5إجراءات الخادم: استبدل REST وقلل النمطية
6. 6dynamic = force-dynamic: احتفظ به للصفحات المخصصة فقط
7. 7تحسين الصور: مكون إلزامي
8. 8تحسين الخطوط: استخدم next/font
9. 9import server-only: امنع تسرب الكود الحساس للعميل
10. 10المسارات الموازية: استخدم @slot للوحات المعقدة

الأخطاء الشائعة

• استخدام useState في مكون خادم ← يتسبب في خطأ
• استخدام fetch في مكون عميل ← تدهور في الأداء (يُفضل الجلب من الخادم)
• تمرير دوال أو تواريخ كـ props ← أخطاء التسلسل
• استيراد مكونات خادم غير متزامنة من ملف "use client" ← قد يسبب تشويشًا

الأسئلة الشائعة (FAQ)

Q1. ما الذي تغير في Next.js 15 App Router؟

أ: تمت إعادة تصميم هيكل التطبيق حول مكونات الخادم والتخطيطات المتداخلة والبث وذاكرة التخزين المؤقت للبيانات.

Q2. هل يجب استخدام App Router أم Pages Router؟

أ: App Router هو الافتراضي للمشاريع الجديدة؛ أما للخدمات القائمة فالأفضل الترحيل تدريجيًا مسارًا بمسار.

Q3. ما أفضل ممارسات مكونات الخادم؟

أ: أبق المكونات كمكونات خادم افتراضيًا، واستخرج فقط الأجزاء التي تتطلب تفاعلًا كمكونات عميل.

Q4. كيف أجلب البيانات في Next.js App Router؟

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

Q5. ما المشكلات الشائعة عند الترحيل إلى App Router؟

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

Q6. ما النقاط الرئيسية لتحسين أداء Next.js 15؟

أ: ضبط حدود التصيير من الخادم، وتحسين الصور، واستراتيجية التخزين المؤقت، وتحليل الحزمة، وتجربة مستخدم البث معًا.

💡 رؤى عملية

معظم المدونات تتوقف عند "App Router رائع، استخدم مكونات الخادم" — لكن في بيئات الإنتاج الكورية، العامل الحاسم هو توافق Cloudflare Pages / Vercel Edge runtime. بعد تشغيل موقع بـ 18 أداة على OpenNext لمدة ستة أشهر، تأكد أن وضع export const runtime = 'edge' في RootLayout أو مسار خاطئ يتسبب في شاشة بيضاء فورية. النهج الأكثر أمانًا هو تركه غير محدد والسماح لـ OpenNext بالتعامل معه تلقائيًا. وفقًا لإحصائيات npm 2024، تجاوز اعتماد App Router نظير Pages Router (67% مقابل 33%). للمشاريع الجديدة، App Router هو التوصية الواضحة؛ أما لقواعد الكود القديمة فالترحيل مسارًا بمسار هو المسار الواقعي.

الخلاصة

يتطلب App Router منحنى تعلم أولي، لكن بمجرد إتقانه، تحصل على أفضل ما في SPA وSSR معًا في تجربة التطوير. لأي مشروع Next.js جديد في 2026، App Router هو الطريق الصحيح. Pages Router هو هدف الترحيل.

مرجع: وثائق مطور Cloudflare