Next.js 9 | Next.js العربية

بعد 70 إصدار تجريبي، يسعدنا تقديم Next.js 9 الذي يتضمن:

دعم TypeScript المدمج بدون تكوين: أنشئ تطبيقك بثقة أكبر بفضل دعم TypeScript التلقائي والتحقق من الأنواع المدمج.
التوجيه الديناميكي القائم على نظام الملفات: عبر عن متطلبات التوجيه المعقدة للتطبيق من خلال نظام الملفات دون الحاجة إلى خادم مخصص.
التحسين التلقائي للمحتوى الثابت: أنشئ مواقع ويب فائقة السرعة تستفيد من عرض جانب الخادم (SSR) والتجهيز المسبق الثابت افتراضيًا دون المساومة على الميزات.
مسارات API: أنشئ نقاط نهاية لتطبيقات الواجهة الخلفية بسرعة، مع الاستفادة من إعادة التحميل الساخن وخطوة بناء موحدة.
المزيد من تحسينات الإنتاج: التطبيقات أصبحت أكثر استجابة من أي وقت مضى بفضل الجلب المسبق داخل نطاق العرض وتحسينات أخرى.
تحسينات تجربة المطور: تحسينات غير مزعجة لسهولة الاستخدام لمساعدتك على التطوير بأفضل شكل.

كما هو الحال دائمًا، حرصنا على ضمان توافق جميع هذه الميزات مع الإصدارات السابقة. بالنسبة لمعظم تطبيقات Next.js، كل ما تحتاجه هو تشغيل:

Terminal

npm i next@latest react@latest react-dom@latest

هناك حالات قليلة جدًا قد تتطلب فيها قاعدة التعليمات البرمجية الخاصة بك تغييرات. راجع دليل الترقية لمزيد من المعلومات.

منذ آخر إصدار لدينا، يسعدنا رؤية شركات مثل IGN، Bang & Olufsen، Intercom، Buffer، و Ferrari تطلق مع Next.js. تحقق من معرض الأعمال للمزيد!

دعم TypeScript المدمج بدون تكوين

قبل عام واحد، قدم Next.js 6 دعمًا أساسيًا لـ TypeScript من خلال مكون إضافي يسمى @zeit/next-typescript. كان على المستخدمين أيضًا تخصيص ملف .babelrc الخاص بهم وتمكينه في next.config.js.

عند التكوين، كان المكون الإضافي يسمح ببناء ملفات .ts و .tsx بواسطة Next.js. ومع ذلك، لم يكن يتضمن التحقق من الأنواع، ولم تكن الأنواع متوفرة من خلال نواة Next.js. هذا يعني أنه كان يجب الحفاظ على حزمة المجتمع بشكل منفصل في DefinitelyTyped والتي يمكن أن تكون غير متزامنة مع الإصدارات.

أثناء التحدث مع العديد من المستخدمين، الحاليين والجدد، أصبح من الواضح أن معظمهم كانوا مهتمين جدًا باستخدام TypeScript. لقد أرادوا حلًا أكثر موثوقية ومعياريًا لدمج TypeScript بسهولة في قاعدة التعليمات البرمجية الحالية أو الجديدة.

لهذا السبب، شرعنا في دمج دعم TypeScript في نواة Next.js، وتحسين تجربة المطور، وجعلها أسرع في هذه العملية.

الإعداد الآلي

البدء باستخدام TypeScript في Next.js سهل: قم بإعادة تسمية أي ملف أو صفحة أو مكون، من .js إلى .tsx. ثم، قم بتشغيل next dev!

هذا سيجعل Next.js يكتشف أن TypeScript مستخدم في مشروعك. سيقودك واجهة سطر أوامر Next.js خلال تثبيت الأنواع الضرورية لـ React و Node.js.

سيقوم Next.js أيضًا بإنشاء ملف tsconfig.json افتراضي بإعدادات معقولة إذا لم يكن موجودًا بالفعل. يسمح هذا الملف بالتحقق المدمج من الأنواع في المحررات مثل Visual Studio Code.

إعداد TypeScript الآلي في Next.js 9

التحقق المدمج من الأنواع

يتعامل Next.js مع التحقق من الأنواع لك في كل من وضع التطوير والبناء للإنتاج.

أثناء التطوير، سيعرض لك Next.js أخطاء الأنواع بعد حفظ الملف. يحدث التحقق من الأنواع في الخلفية، مما يسمح لك بالتفاعل مع تطبيقك المحدث في المتصفح على الفور. ستنتشر أخطاء الأنواع إلى المتصفح بمجرد توفرها.

التحقق من الأنواع في التطوير في Next.js 9

سيقوم Next.js أيضًا بإفشال بناء الإنتاج (أي next build) تلقائيًا إذا كانت هناك أخطاء في الأنواع. هذا يساعد في منع إرسال كود معطوب إلى الإنتاج.

التحقق من الأنواع في الإنتاج في Next.js 9

نواة Next.js مكتوبة بـ TypeScript

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

على سبيل المثال، عند استيراد next/link، ستظهر المحررات التي تدعم TypeScript الخصائص المسموح بها والقيم التي تقبلها.

أنواع نواة Next.js

شرائح المسار الديناميكي

كان التوجيه الديناميكي (المعروف أيضًا باسم مسارات URL الجميلة أو النظيفة) أحد أول طلبات الميزات على GitHub بعد إطلاق Next.js منذ 2.5 سنة!

تم "حل" المشكلة في Next.js 2.0 من خلال تقديم واجهة برمجة التطبيقات للخادم المخصص لاستخدام Next.js برمجيًا. هذا سمح باستخدام Next.js كمحرك عرض، مما مكّن من التجريدات وتعيين عناوين URL الواردة لعرض صفحات معينة.

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

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

نظرًا لأن الخادم المخصص يتطلب أن يكون التطبيق بأكمله متاحًا في مثيل واحد، فمن الصعب عادةً نشره في بيئة Serverless التي تحل هذه المشكلات. يتم توجيه طلبات Serverless في طبقة الوكيل ويتم توسيعها/تنفيذها بشكل مستقل لتجنب اختناقات الأداء.

بالإضافة إلى ذلك، نعتقد أنه يمكننا تقديم تجربة مطور أفضل! يبدأ الكثير من سحر Next.js عندما تقوم بإنشاء ملف باسم pages/blog.js وفجأة لديك صفحة يمكن الوصول إليها في /blog.

لماذا يجب على المستخدم إنشاء خادمه الخاص وتعلم واجهة برمجة التطبيقات البرمجية لـ Next.js لدعم مسار مثل /blog/my-first-post (/blog/:id)؟

بناءً على هذه الملاحظات والرؤية، بدأنا في التحقيق في حلول تعيين المسارات، مدفوعة بما يعرفه المستخدمون بالفعل: دليل pages/.

إنشاء صفحة موجهة ديناميكيًا

يدعم Next.js إنشاء مسارات باستخدام معلمات مسماة أساسية، وهو نمط شاع استخدامه بواسطة path-to-regexp (المكتبة التي تعمل على تشغيل Express).

يمكن الآن تحقيق إنشاء صفحة تطابق المسار /post/:pid عن طريق إنشاء ملف في دليل pages الخاص بك باسم: pages/post/[pid].js!

سيتطابق Next.js تلقائيًا مع الطلبات مثل /post/1، /post/hello-nextjs، وما إلى ذلك ويعرض الصفحة المحددة في pages/post/[pid].js. سيتم تمرير مقطع URL المطابق كمعلمة استعلام إلى صفحتك بالاسم المحدد بين [الأقواس المربعة].

على سبيل المثال: بالنظر إلى الصفحة التالية والطلب /post/hello-nextjs، سيكون كائن query هو { pid: 'hello-nextjs' }:

static async getInitialProps({ query }) {
  // pid = 'hello-nextjs'
  const { pid } = query
 
  const postContent = await fetch(
    `https://api.example.com/post/${encodeURIComponent(pid)}`
  ).then(r => r.text())
 
  return { postContent }
}

كما يتم دعم مقاطع URL الديناميكية المتعددة!

يتم دعم بناء الجملة [param] لأسماء الدلائل وأسماء الملفات، مما يعني أن الأمثلة التالية تعمل:

./pages/blog/[blogId]/comments/[commentId].js
./pages/posts/[pid]/index.js

التحسين التلقائي للمحتوى الثابت

أضاف Next.js دعمًا لإنشاء مواقع ويب ثابتة في الإصدار v3، الذي تم إصداره منذ حوالي عامين. في ذلك الوقت، كانت هذه الميزة هي الأكثر طلبًا لإضافتها إلى Next.js.

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

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

في الواقع، يمكن أن يكون للتطبيقات متطلبات مختلفة. تتطلب هذه المتطلبات استراتيجيات عرض مختلفة ومقايضات.

على سبيل المثال، تحتوي الصفحة الرئيسية وصفحات التسويق عادةً على محتوى ثابت وهي مرشحة رائعة للتحسين الثابت.

من ناحية أخرى، قد يستفيد لوحة تحكم المنتج من عرض جانب الخادم حيث يتم تحديث البيانات بشكل متكرر.

بدأنا في استكشاف كيف يمكننا منح المستخدمين أفضل ما في العالمين وأن نكون سريعين افتراضيًا. كيف يمكننا منح المستخدمين صفحات تسويق ثابتة وصفحات معروضة على الخادم ديناميكيًا؟

بدءًا من Next.js 9، لم يعد على المستخدمين الاختيار بين عرض جانب الخادم بالكامل أو تصدير تطبيقاتهم بشكل ثابت. مما يمنحك أفضل ما في العالمين على أساس كل صفحة.

التصدير الثابت الجزئي التلقائي

تم تقديم إرشادي لتحديد تلقائيًا ما إذا كان يمكن تجهيز الصفحة مسبقًا إلى HTML ثابت.

يتم اتخاذ هذا القرار بناءً على ما إذا كانت الصفحة تحتوي على متطلبات بيانات حظر من خلال استخدام getInitialProps.

يسمح هذا الإرشادي لـ Next.js بإصدار تطبيقات هجينة تحتوي على صفحات معروضة على الخادم وصفحات تم إنشاؤها بشكل ثابت.

يدعم كل من خادم Next.js المدمج (next start) وواجهة برمجة التطبيقات البرمجية (app.getRequestHandler()) ناتج البناء هذا بشكل شفاف. لا يلزم أي تكوين أو معالجة خاصة.

تظل الصفحات التي تم إنشاؤها بشكل ثابت تفاعلية: سيقوم Next.js بترطيب تطبيقك على جانب العميل لمنحه تفاعلًا كاملاً.

علاوة على ذلك، سيقوم Next.js بتحديث تطبيقك بعد الترطيب إذا كانت الصفحة تعتمد على معلمات الاستعلام في عنوان URL.

سيقوم Next.js بإعلامك مرئيًا إذا كانت الصفحة سيتم إنشاؤها بشكل ثابت أثناء التطوير. يمكن إخفاء هذه الأداة المرئية بالنقر عليها.

مؤشر التحسين الثابت في Next.js

سيتم أيضًا عرض الصفحات التي تم إنشاؤها بشكل ثابت في ناتج بناء Next.js:

مؤشر نوع ناتج البناء في Next.js

مسارات API

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

وجدنا أن العديد من المستخدمين الذين يحتاجون إلى واجهة خلفية قاموا ببناء واجهة برمجة التطبيقات الخاصة بهم باستخدام خادم مخصص. عند القيام بذلك، واجهوا عددًا من المشكلات. على سبيل المثال، لا يقوم Next.js بتجميع كود الخادم المخصص، مما يعني أنك لا تستطيع استخدام import / export أو TypeScript.

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

أثار هذا السؤال: ماذا لو جلبنا تجربة المطور التي يوفرها Next.js لبناء واجهات خلفية API؟

اليوم، يسعدنا تقديم مسارات API، تجربة المطور الأفضل في فئتها من Next.js لبناء واجهتك الخلفية.

للبدء في استخدام مسارات API، تقوم بإنشاء دليل يسمى api/ داخل دليل pages/.

سيتم تعيين أي ملف في هذا الدليل تلقائيًا إلى /api/<مسارك>، بنفس الطريقة التي يتم بها تعيين ملفات الصفحات الأخرى إلى المسارات.

على سبيل المثال، سيتم تعيين pages/api/contact.js إلى /api/contact.

ملاحظة: تدعم مسارات API أيضًا المسارات الديناميكية!

تصدر جميع الملفات داخل دليل pages/api/ دالة معالجة طلب بدلاً من مكون React:

export default function handle(req, res) {
  res.end('Hello World');
}

يشير req إلى NextApiRequest الذي يمتد http.IncomingMessage
يشير res إلى NextApiResponse الذي يمتد http.ServerResponse

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

عند التحقيق في إضافة دعم مسارات API إلى Next.js، لاحظنا أنه في كثير من الحالات لم يستخدم المستخدمون كائنات طلب Node.js والاستجابة مباشرة. بدلاً من ذلك، استخدموا تجريدًا مقدماً من مكتبات الخادم مثل Express.

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

ستوفر مسارات API في Next.js هذه البرامج الوسيطة افتراضيًا حتى تتمكن من أن تكون منتجًا في إنشاء نقاط نهاية API على الفور:

export default function handle(req, res) {
  console.log(req.body); // جسم الطلب
  console.log(req.query); // سلسلة استعلام URL
  console.log(req.cookies); // ملفات تعريف الارتباط الممررة
  res.end('Hello World');
}

بالإضافة إلى استخدام البيانات الواردة، تقوم نقطة نهاية API بشكل عام بإرجاع البيانات أيضًا. عادةً ما يكون هذا الرد بتنسيق JSON. يوفر Next.js res.json() افتراضيًا لتسهيل إرسال البيانات:

export default function handle(req, res) {
  res.json({ title: 'Hello World' });
}

عند إجراء تغييرات على نقاط نهاية API في التطوير، يتم إعادة تحميل الكود تلقائيًا، لذلك ليست هناك حاجة لإعادة تشغيل الخادم.

تحسينات الإنتاج

الجلب المسبق لروابط `<Link>` داخل نطاق العرض

سيقوم Next.js 9 تلقائيًا بجلب مكونات <Link> مسبقًا عند ظهورها داخل نطاق العرض.

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

يستخدم Next.js مراقب التقاطع (Intersection Observer) لـ جلب الأصول المطلوبة مسبقًا في الخلفية.

تحتوي هذه الطلبات على أولوية منخفضة وتتنازل لطلبات fetch() أو XHR. سيتجنب Next.js الجلب المسبق التلقائي إذا كان المستخدم قد مكّن توفير البيانات.

يمكنك إلغاء الاشتراك في هذه الميزة للصفحات التي يتم زيارتها نادرًا عن طريق تعيين خاصية prefetch إلى false:

<Link href="/terms" prefetch={false}>
  <a>شروط الخدمة</a>
</Link>

تحسين AMP افتراضيًا

الآن يُصدر Next.js 9 صفحات AMP محسنة افتراضيًا لصفحات AMP-first والهجينة.

بينما صفحات AMP اختيارية، فإن Next.js سيقوم تلقائيًا بتحسين مخرجاتها. هذه التحسينات يمكن أن تؤدي إلى زيادة سرعة التصيير بنسبة 50%!

هذا التغيير أصبح ممكنًا بفضل العمل الرائع لـ Sebastian Benz على AMP Optimizer.

إزالة الشفرات غير المستخدمة لفروع `typeof window`

يقوم Next.js 9 باستبدال typeof window بقيمته المناسبة (undefined أو object) أثناء بناء الخادم والعميل. هذا التغيير يسمح لـ Next.js بإزالة الشفرات غير المستخدمة تلقائيًا من تطبيقك المُنشأ للإنتاج.

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

تحسينات تجربة المطور

مؤشر الترجمة

في الإصدارات السابقة للإصدار 9، كانت الطريقة الوحيدة لمعرفة أن استبدال الشفرة الساخن سيحدث (وأن سلسلة أدوات مترجم Next.js تعمل) هي النظر إلى وحدة تحكم المطور.

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

لهذا السبب أنشأنا RFC / "مهمة أولى جيدة" لمناقشة الحلول المحتملة لمشكلة الإشارة إلى أن العمل يجري.

تلقينا تعليقات من العديد من المصممين والمهندسين على RFC، على سبيل المثال ما يفضلونه والاتجاهات المحتملة لتصميم المؤشر.

استغل Rafael Almeida هذه الفرصة للتعاون مع فريقنا وتنفيذ مؤشر جديد تمامًا متاح الآن افتراضيًا في Next.js 9.

عندما يكون Next.js يقوم بأعمال الترجمة، سترى مثلثًا صغيرًا يظهر في الزاوية اليمنى السفلية من الصفحة!

مؤشر ترجمة Next.js

إخراج وحدة التحكم

تقليديًا عند إجراء تغييرات في وضع التطوير، كان Next.js يُظهر حالة مؤشر الترجمة مع أشرطة حالة التحميل التي تمتلئ وكان يمسح الشاشة باستمرار أثناء إجراء التغييرات.

هذا السلوك يسبب بعض المشكلات. أبرزها أنه كان يمسح إخراج وحدة التحكم من كود التطبيق الخاص بك، على سبيل المثال عند إضافة console.log إلى مكوناتك. ولكن أيضًا عند استخدام أدوات خارجية تجمع إخراج السجلات معًا مثل Vercel CLI أو docker-compose.

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

إخراج وحدة تحكم تطوير Next.js

شكر خاص لـ Justin Chase للتعاون على مسح الإخراج.

إحصائيات إخراج البناء

عند بناء تطبيقك للإنتاج باستخدام next build، سيعطيك الآن عرضًا تفصيليًا لجميع الصفحات التي تم بناؤها.

كل صفحة تحصل تلقائيًا على بعض الإحصائيات.

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

حجم صفحة Next.js المبنية

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

عدد حزم صفحة Next.js

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

نوع صفحة Next.js المبنية

كائن التهيئة لكل صفحة

يمكن لكل صفحة الآن تصدير كائن تهيئة. في البداية تسمح هذه التهيئة بالاشتراك في AMP، ولكن في المستقبل ستتمكن من تكوين المزيد من الخيارات الخاصة بالصفحة.

pages/about.js

export const config = { amp: true };
 
export default function AboutPage(props) {
  return <h3>My AMP About Page!</h3>;
}

للاشتراك في تصيير AMP الهجين يمكنك استخدام القيمة 'hybrid':

pages/about.js

import { useAmp } from 'next/amp';
 
export const config = { amp: 'hybrid' };
 
export default function AboutPage(props) {
  const isAmp = useAmp();
  return <h3>My About Page!{isAmp ? <> Powered by AMP!</> : ''}</h3>;
}

تمت إزالة مكون الترتيب الأعلى withAmp لصالح كائن التهيئة الجديد هذا.

لقد قدمنا codemod يحول استخدام withAmp تلقائيًا إلى كائن التهيئة الجديد. يمكنك قراءة المزيد عن هذا في دليل الترقية.

تحسينات قاعدة الشفرة

لقد أجرينا مؤخرًا بعض التغييرات على أدواتنا لتوفير تجربة أفضل أثناء المساهمة في قاعدة الشفرة وضمان الاستقرار مع نمو قاعدة الشفرة.

كما قرأت في قسم TypeScript، فإن نواة Next.js مكتوبة الآن في TypeScript ويتم إنشاء الأنواع تلقائيًا لتطبيقات Next.js لاستخدامها. بالإضافة إلى كون هذا مفيدًا للتطبيقات المبنية باستخدام Next.js، فهو مفيد أيضًا عند العمل على قاعدة شفرة النواة. حيث تحصل على أخطاء الكتابة والإكمال التلقائي تلقائيًا.

كان لدى Next.js بالفعل مجموعة كبيرة من اختبارات التكامل تتكون من 50+ تطبيق Next.js مع اختبارات تعمل ضدها. تضمن هذه الاختبارات أنه عند إصدار نسخة جديدة، تكون الترقية سلسة حيث تم اختبار الميزات التي كانت متاحة من قبل ضد نفس مجموعة الاختبار.

معظم اختباراتنا هي اختبارات تكامل لأنه في كثير من الحالات تكرر "مطورين حقيقيين" يستخدمون Next.js في التطوير. على سبيل المثال لدينا اختبارات تكرر إجراء تغييرات على تطبيق Next.js لمعرفة ما إذا كان استبدال الوحدة الساخن يعمل.

تعتمد اختبارات التكامل لدينا في الغالب على Selenium webdriver، والذي جمّعناه مع chromedriver للاختبار في Chrome بدون واجهة. ولكن مع مرور الوقت ظهرت بعض المشكلات في متصفحات أخرى، خاصة المتصفحات القديمة مثل Internet Explorer 11.

لأننا استخدمنا Selenium، تمكنا من تشغيل اختباراتنا تلقائيًا على متصفحات متعددة.

حاليًا نقوم بتشغيل مجموعة اختباراتنا على Chrome و Firefox و Safari و Internet Explorer 11.

تعاون Google Chrome

يعمل فريق Google Chrome على تحسين Next.js من خلال المساهمة بـ RFCs وطلبات السحب.

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

على سبيل المثال، ستؤدي هذه التغييرات إلى تحسين تجربة المواقع الصغيرة، ولكن أيضًا تطبيقات ضخمة مثل Hulu، Twitch، و Deliveroo.

Module / Nomodule

أول مجال تركيز هو إرسال JavaScript الحديث إلى المتصفحات التي تدعم JavaScript الحديث.

على سبيل المثال، حاليًا يجب على Next.js توفير polyfills لصيغة async/await حيث قد يتم تنفيذ الشفرة في متصفحات لا تدعم async/await مما قد يؤدي إلى كسرها.

RFC تعاون Module/Nomodule لـ Next.js

لتجنب كسر المتصفحات القديمة مع الاستمرار في إرسال JavaScript الحديث إلى المتصفحات التي تدعمه، سوف يستخدم Next.js نمط module/nomodule. يوفر نمط module/nomodule آلية موثوقة لتقديم JavaScript الحديث إلى المتصفحات الحديثة مع السماح للمتصفحات القديمة بالتراجع إلى ES5 مع polyfills.

يمكن العثور على RFC لـ module/nomodule في Next.js هنا.

تحسين تقسيم الحزم

استراتيجية تقسيم الحزم الحالية في Next.js تعتمد على إرشادي نسبة لإدراج الوحدات في حزمة "مشتركة" واحدة. نظرًا لوجود القليل من التدرج حيث توجد حزمة واحدة فقط، إما يتم تنزيل الشفرة دون داع (لأن الحزمة المشتركة قد تتضمن شفرة غير مطلوبة لمسار معين) أو يتم تكرار الشفرة عبر عدة حزم صفحات.

RFC تعاون التقسيم لـ Next.js

يمكن العثور على RFC لتحسين تقسيم الحزم هنا.

تحسينات أخرى

يعمل فريق Chrome أيضًا على العديد من التحسينات والتغييرات الأخرى التي ستحسن Next.js. سيتم مشاركة RFCs لهذه قريبًا.

تم وضع علامة "Collaboration" على هذه RFCs وطلبات السحب بحيث يمكن العثور عليها بسهولة في متتبع مشكلات Next.js.

المجتمع

نحن متحمسون لرؤية النمو المستمر لمجتمع Next.js.

هذا الإصدار شهد أكثر من 65 مؤلف طلب سحب يقدمون تحسينات أساسية أو أمثلة.

بالحديث عن الأمثلة، نحن نقدم الآن أكثر من 200 مثال حول كيفية دمج Next.js مع مكتبات وتقنيات مختلفة! بما في ذلك معظم مكتبات css-in-js وجلب البيانات.

لدينا أكثر من 720 مساهمًا قاموا بإيداع commit واحد على الأقل.
على GitHub، تم وضع نجمة للمشروع أكثر من 38,600 مرة.
تم تقديم أكثر من 3,400 طلب سحب منذ الإصدار الأول، أي أكثر من 800 منذ الإصدار الرئيسي الأخير!

لقد تضاعف مجتمع Next.js منذ الإصدار الرئيسي الأخير ليصل إلى أكثر من 8,600 عضو. انضم إلينا!

نحن ممتنون لمجتمعنا وجميع التعليقات والمساهمات الخارجية التي ساعدت في تشكيل هذا الإصدار.