هذا الدليل للفرق التي تشغّل تطبيقًا على Next.js 15 أو ترحّله إليه، وليس نصيحة بشأن أحدث إصدار من Next.js. فإن كنت تبدأ مشروعًا جديدًا، فابدأ بإصدار مدعوم حاليًا ووثائقه الخاصة. أما إن كنت تصون قاعدة كود على Next.js 15، فثلاث مناطق تستحق نظرة فاحصة: واجهات طلب أصبحت غير متزامنة، وافتراضات تخزين مؤقت تغيّرت، والحد الفاصل بين المحتوى المخزّن وبيانات كل مستخدم. أتقن هذه الثلاث، وأبقِ الإطار محدّثًا أمنيًا، وتحقق من النتيجة ببيانات المستخدمين الحقيقيين.
تصف ملاحظات إصدار Next.js 15 التغييرات مقارنة بالإصدار 14، وهكذا يستخدمها هذا الدليل: خريطة لإكمال الترحيل وتشغيل هذا الإصدار بأمان. وتترتب على ذلك قاعدتان عمليتان.
الأولى: لا تثبّت إصدار تصحيح قديمًا. فالمشروع يصلح ثغرات الإطار في إصدارات أحدث، لذا تابع تنبيهاته الأمنية، وطبّق التحديثات الأمنية دون تأخير، وتحقق من خطوط الإصدار التي تتلقى إصلاحات حاليًا.
الثانية: خطط للترقية التالية وأنت تصون هذا الإصدار. فكل ما يلي، من التخزين المؤقت الصريح إلى التحقق من الصلاحيات قرب البيانات، يسهّل الترقيات اللاحقة أيضًا، لأن سلوك تطبيقك لم يعد يعتمد على افتراضات قد تتغير مجددًا.
في Next.js 15 أصبحت الواجهات التي تقرأ بيانات الطلب غير متزامنة: cookies() وheaders() وdraftMode()، إضافة إلى params في نقاط المسارات ذات الصلة، كالصفحات والتخطيطات ومعالجات المسارات ودوال البيانات الوصفية. أما الخاصية غير المتزامنة searchParams فتخص الصفحات؛ ولا تتلقاها التخطيطات، وتقرأ معالجات المسارات معاملات الاستعلام من عنوان الطلب. وتعرض ملاحظات الإصدار ذلك بوصفه مرحلة انتقالية، وتوفر أداة Codemod تحدّث معظم مواضع الاستدعاء.
من الـCodemod يبدأ العمل:
- ابحث عن الدوال المغلِّفة. الدوال المساعدة التي تقرأ ملفات تعريف الارتباط أو الترويسات للمصادقة أو اللغة أو مفاتيح الميزات يسهل أن تفوتك. اجعل الدوال الخادمية غير متزامنة وعالج وعودها قبل استخدام القيم. وراجع الجهات المستهلكة في المتصفح على حدة بدل جعل Client Components غير متزامنة.
- راجع معالجة اللغة. في موقع ثنائي اللغة تصل اللغة عادةً عبر
params، فانتظرها في كل صفحة وكل دالة بيانات وصفية تختار المحتوى العربي أو الإنجليزي. - اعتبر أي وصول متزامن متبقٍّ عملًا ترحيليًا لم يكتمل، وأصلح التحذيرات المرتبطة به بدل إسكاتها.
- شغّل فحص الأنواع بعد الـCodemod. سيكشف TypeScript مواضع كثيرة يُستخدم فيها وعدٌ (Promise) كأنه قيمة.
غيّر Next.js 15 عدة افتراضات للتخزين المؤقت. فبحسب ملاحظات الإصدار، لم تعد معالجات مسارات GET تُخزَّن افتراضيًا، كما تصف الملاحظات تغييرات مرتبطة بطريقة تخزين طلبات fetch والتنقل من جهة المتصفح. أي أن نقطة نهاية كانت تُقدَّم من التخزين المؤقت في الإصدار 14 قد تعمل الآن مع كل طلب.
هذا لا يعني تعطيل كل التخزين. فقد تبقى مسارات البيانات الوصفية الخاصة ثابتة، وتحتفظ التخطيطات المشتركة والتنقلات للخلف والأمام بسلوك تخزين في المتصفح. والتوليد الثابت ومخابئ البيانات الصريحة وشبكة CDN الخارجية طبقات منفصلة، وعليك فحص كل واحدة منها. اجعل كل قرار تخزين مقصودًا:
- أحصِ معالجات المسارات ودوال جلب البيانات والصفحات، وحدّد أيها كان يعتمد على سلوك التخزين القديم.
- قرّر لكل مورد هل محتواه عام، وكم يُسمح أن يكون قديمًا، وما الحدث الذي يجب أن يحدّثه، مثل نشر في نظام إدارة المحتوى أو تغيير سعر.
- فعّل التخزين صراحةً حيث يكون صحيحًا، بخيارات المسارات و
fetchالموثقة لإصدارك تحديدًا، واربط إعادة التحقق بالأحداث التي تغيّر البيانات. - راقب الخادم الأصلي. بعد النشر، تابع عدد الطلبات وأزمنة الاستجابة على الخادم الأصلي ومصادر البيانات، حتى يظهر التخزين المفقود في مقياس لا في انقطاع للخدمة.
وإن كان محتواك يأتي من نظام إدارة محتوى بواجهة مستقلة، فحدد الحقول التي تقود إعادة التحقق ضمن نموذج المحتوى نفسه؛ ويتناول دليلنا عن تصميم نماذج المحتوى في أنظمة إدارة المحتوى المستقلة هذه الملكية.
شكل 1: افحص كل طبقة تخزين مؤقت. تغيّرت الافتراضات وبقيت مخابئ أخرى.
يحمل التخزين المؤقت الصريح خطرًا جديًا واحدًا: تخزين ما يخص مستخدمًا واحدًا. فالاستجابة التي تتضمن سلة مشتريات أو بيانات حساب أو أسعارًا لفئة عملاء محددة يجب ألا تصل أبدًا إلى تخزين قد يتلقاه زائر آخر.
قواعد عملية:
- أبعد قراءات المستخدم عن أي دالة أو مسار تعلّمه قابلًا للتخزين.
- إن كان التخزين لكل مستخدم مبررًا، فضمّن المستأجر والمستخدم ونطاق المورد في المفتاح، وتحقق من الصلاحية الحالية قبل إعادة نتيجة مخزنة، وأبطل التخزين عند تغيرها. فشريحة العملاء وحدها ليست مفتاحًا آمنًا لبيانات الحساب الفردي.
- افصل البيانات العامة القابلة للتخزين عن القراءات الشخصية المصرح بها. ولا تفترض أن مزجهما ينتج من تلقاء نفسه هيكلًا عامًا ثابتًا؛ بل تحقق من سلوك التوليد الذي يدعمه إعداد Next.js 15 المحدد لديك.
- اختبر ذلك: سجّل الدخول بمستخدمَين مختلفين وباللغتين، وتأكد أن أيًّا منهما لا يرى بيانات الآخر أبدًا، بما في ذلك بعد النشر وإعادة التحقق وتسجيل الخروج وتغيير الأدوار والتنقل بين المستأجرين.
يبقى كود Server Components على الخادم، لكن المحتوى والخصائص الناتجة قد تصل إلى المتصفح. وتعامل مع Server Actions القابلة للاستدعاء كنقاط HTTP عامة: فطلب مصطنع يستطيع استدعاءها مباشرة، والفحص الموضوع في تخطيط أو في Middleware وحده قد لا يعمل مع كل طريق يصل إلى البيانات.
وإرشادنا أن تتحقق من الصلاحيات في أقرب نقطة ممكنة من البيانات:
- ضع فحوص المصادقة والصلاحيات في طبقة وصول إلى البيانات تستخدمها كل Server Components ومعالجات المسارات وServer Actions.
- تحقق من صلاحيات المستخدم داخل كل Server Action، بهويته المأخوذة من الجلسة على الخادم، لا من حقول النموذج.
- استخدم Middleware للتوجيه العام، مثل إعادة توجيه الزوار غير المسجلين، لا بوابةً وحيدة.
- أعد الحقول التي تحتاجها الصفحة فقط، حتى لا تصل أعمدة حساسة إلى المتصفح مصادفة.
شكل 2: تحقق من صلاحيات الوصول للبيانات. تعامل مع الإجراءات كنقاط قابلة للاستدعاء.
نجاح البناء لا يخبرك شيئًا عن تجربة الزوار الحقيقيين. قارن البيانات الميدانية قبل الترحيل وبعده حسب قالب الصفحة ونوع الجهاز واللغة. وتقيّم إرشادات Google لمؤشرات أداء الويب الصفحات عند المئين 75 من الزيارات الحقيقية، مع الفصل بين الجوال وسطح المكتب، وعتباتها الجيدة: 2.5 ثانية أو أقل لـLCP، و200 ملّي ثانية أو أقل لـINP، و0.1 أو أقل لـCLS. تساعدك الاختبارات المختبرية على إعادة إنتاج المشكلات، لكن البيانات الميدانية هي التي تؤكد الإصلاح. واجتياز هذه العتبات هدف لتجربة المستخدم لا ضمان للترتيب في البحث؛ ويعرض دليلنا عن مؤشرات أداء الويب الأساسية مسارًا لتحديد الصفحات البطيئة وإصلاحها.
- مراجعة التنبيهات الأمنية وتحديث الإطار خلال مدة متفق عليها بعد نشر الإصلاح.
- لا وصول متزامن متبقٍّ إلى واجهات الطلب، ولا تحذيرات مرتبطة به في الكود.
- قائمة مكتوبة بما يُخزَّن، ولأي مدة، وما الذي يحدّثه.
- اختبار بمستخدمَين وبلغتين للبيانات الشخصية في كل إصدار.
- فحوص الصلاحيات في طبقة البيانات وفي كل Server Action.
- متابعة المقاييس الميدانية حسب القالب والجهاز واللغة بعد كل إصدار.
- خطة ترقية إلى إصدار مدعوم حاليًا تُراجع كل ربع سنة.
وتندرج هذه الخيارات ضمن قرارات أوسع يتناولها دليلنا عن قرارات المعمارية من المنتج الأولي إلى التوسع. وإن كنت تحتاج إلى مساعدة في صيانة موقع Next.js أو ترقيته، فإن خدمة تصميم وتطوير المواقع لدينا تشمل التدقيق والترحيل والدعم المستمر.
- Vercel. Next.js 15 release notes: واجهات الطلب غير المتزامنة، وأداة Codemod للترقية، وتغييرات افتراضات التخزين المؤقت ومنها معالجات مسارات GET.
- Google. Web Vitals: مؤشرات أداء الويب الأساسية الحالية وعتباتها الجيدة وتقييمها عند المئين 75.
هذا الدليل خاص بـNext.js 15، فراجع وثائق إصدارك تحديدًا قبل تغيير الإعدادات. والتوصيات الواردة فيه إرشادات من تكنوستاك، لا متطلبات من Vercel أو Google.
