الإصدار 9.1 من Next.js

اليوم، يسعدنا الإعلان عن Next.js 9.1 مع دعم مجلدات src و public.

ما الجديد في هذا الإصدار

• دعم مجلد src: يمكن الآن تداخل مجلد pages تحت مجلد src، مما يدعم مجموعة أوسع من إعدادات التطبيقات.
• دعم مجلد public: تحديد الملفات ليتم تركيبها في جذر عنوان URL لتطبيقك (مثل favicon.ico).

المعاينة في هذا الإصدار

• الدعم المدمج لـ CSS: سيتمكن التطبيقات قريبًا من استيراد CSS العام والاستفادة من إعادة التحميل الساخن أثناء التطوير وتحسينات الإنتاج المتقدمة، التجميع، والتعبئة.
• صفحات الأخطاء الثابتة: تصدير صفحات الأخطاء المتوقعة (مثل 404) بشكل ثابت لتحسين التوفر (CDN).
• Module / Nomodule: إرسال حزم JavaScript أصغر للمستخدمين النهائيين الذين يعملون على متصفحات حديثة.
• تحسين تقسيم الحزم: إرسال عدد أقل من البايتات إلى المستخدم النهائي، مما يحسن وقت التفاعل الأولي (TTI) وسرعة انتقال الصفحة. كما يتم تخزين أجزاء المكتبات الكبيرة مؤقتًا لفترات طويلة عبر عمليات النشر.

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

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

إذا كان تطبيقك على إصدار من Next.js قبل الإصدار 9، يمكنك الرجوع إلى دليل الترقية للتغييرات التي قد تحتاج إلى ترقيتها.

منذ آخر إصدار رئيسي لنا، يسعدنا أن نرى شركات مثل TikTok، Hilton، Elastic، Realtor، و JW Player تطلق مع Next.js. تحقق من المعرض للمزيد!

دعم مجلد src

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

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

بدءًا من Next.js 9.1، أصبح من الممكن الآن إنشاء مجلد src/pages بدلاً من إنشاء مجلد pages في جذر التطبيق.

استخدام مجلد src اختياري ويغطي الحالة التي يكون فيها لشركتك هذا المعيار موجودًا بالفعل.

مجلد pages داخل مجلد src

دعم مجلد public

بالإضافة إلى مجلد pages، يحتوي Next.js على مجلد خاص آخر يسمى static، حيث كانت الملفات الخاصة به تُرسم إلى مسار /static.

على سبيل المثال، static/my-image.png سيتم تعيينه إلى /static/my-image.png.

هذا الاتفاق عمل بشكل جيد منذ الإصدار الأول لـ Next.js وليس به مشاكل معينة.

ومع ذلك، بمرور الوقت وجدنا أن /static لا يغطي كل ما هو مطلوب في تطبيق ويب. على سبيل المثال، يجب تقديم robots.txt من جذر النطاق.

بدءًا من Next.js 9.1، نقدم مجلدًا جديدًا يسمى public.

سيتم تعيين أي ملفات في مجلد public إلى جذر النطاق.

على سبيل المثال، public/robots.txt سيتم تعيينه إلى /robots.txt.

نظرًا لأن public يغطي أيضًا حالة استخدام مجلد static، فقد قررنا إهمال مجلد static لصالح إنشاء مجلد public/static بنفس الوظيفة.

كما هو الحال دائمًا، نسعى جاهدين للحفاظ على التوافق مع الإصدارات السابقة، لذا سيستمر مجلد static في العمل مع رسالة إهمال.

قريبًا

الميزات التالية حاليًا تحت علم تجريبي وسيتم إصدارها بمجرد اكتمال التنفيذ النهائي.

الدعم المدمج لـ CSS

حاليًا، يحتوي Next.js على حل CSS-in-JS مدمج يسمى styled-jsx. يعمل هذا الحل جيدًا لتنسيق مكونات React الفردية.

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

بشكل عام، يعني هذا إضافة المكوّن الإضافي next-css لإضافة دعم استيراد CSS.

وجدنا أن حوالي 50% من جميع مستخدمي Next.js يضيفون هذا المكوّن الإضافي إلى تطبيقهم.

بسبب هذا الاستخدام الواسع، نضيف دعمًا مدمجًا لاستيراد CSS مع إعادة تحميل تلقائية للأنماط أثناء التطوير وتحسينات الإنتاج التي لم تكن ممكنة سابقًا في المكوّن الإضافي next-css.

يتم حاليًا اختبار التنفيذ الأولي على تطبيقات Next.js الإنتاجية.

سيتم تقديم استيراد CSS العام أولاً:

// يمكن استيراد الأنماط العامة من _app.js
import '../styles/global.css';
import App from 'next/app';
 
export default App;

بعد استيراد CSS العام، سنقدم دعمًا لوحدات CSS من خلال امتداد .module.css:

// يتم استيراد الأنماط المحددة من خلال .module.css
import styles from '../styles/index.module.css';
 
export default function HomePage() {
  return <h1 className={styles.heading}>مرحبًا بالعالم</h1>;
}

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

يمكنك قراءة المزيد عن العمل الجاري على RFC على GitHub.

صفحات الأخطاء الثابتة

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

تنقسم الأخطاء المعروضة بشكل عام إلى حالتين: أخطاء متوقعة وأخطاء غير متوقعة.

الأخطاء المتوقعة هي، على سبيل المثال، صفحة 404.

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

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

سيكون هناك خيار إلغاء إذا أراد المستخدم عرض هذه الصفحات ديناميكيًا، ولكن الافتراضي سيكون أن 404 ستكون صفحة ثابتة. هذا يقلل الحمل على الخادم عند استخدام هدف server ويقلل التكلفة عند استخدام هدف serverless.

فائدة أخرى لجعل الصفحة ثابتة هي أنه يمكن تخزينها مؤقتًا تلقائيًا عند استخدام CDN.

تعاون Google Chrome

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

لمعرفة المزيد عن هذا التعاون، يمكنك قراءة إعلان Next.js 9 ومشاهدة هذه المحادثة التي ألقتها Nicole Sullivan في React Rally.

Module / Nomodule

عند كتابة الكود في Next.js، تكتب بشكل عام JavaScript "حديث". يمكنك استخدام جميع الميزات المستقرة الحديثة وسيتأكد Next.js تلقائيًا من تحويل هذه الميزات أو تعبئتها من خلال تجميع الكود باستخدام Babel.

في هذه المرحلة، يتم دعم العديد من ميزات JavaScript هذه في غالبية المتصفحات. ومع ذلك، بشكل عام (بما في ذلك في Next.js)، يتم إرسال الكود كحزمة JavaScript واحدة تعمل على جميع المتصفحات التي يدعمها تطبيقك.

في حالة Next.js، هذا يعني تجميع JavaScript الحديث إلى تنسيق متوافق مع Internet Explorer 11.

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

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

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

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

يحتوي Next.js حاليًا على عدة حزم JavaScript يقوم بتحميلها لجعل الصفحة تفاعلية. الأكثر ملاحظة:

• حزمة JavaScript للصفحة.
• ملف يحتوي على JavaScript المشترك.
• حزمة وقت تشغيل Next.js من جانب العميل.
• الاستيراد الديناميكي (يتم إضافته بشكل عام عبر next/dynamic).

لضمان تفاعلية الصفحة، يجب تحميل كل هذه الحزم لأنها تعتمد جميعها على بعضها البعض لتتمكن من تشغيل React في المتصفح.

نظرًا لأن هذه الحزم مطلوبة ليتم تحميلها لتشغيل React، فمن المهم أن تكون محسنة قدر الإمكان ولا تقوم بتنزيل الكثير من الكود من بقية التطبيق.

لهذا السبب، هناك حزمة commons تحتوي على JavaScript المشترك بين الصفحات. يعتمد حساب استراتيجية تقسيم الحزم الحالية لإنشاء commons على إرشادي يعتمد على النسبة، إذا تم استخدام وحدة في 50% من جميع الصفحات فسيتم وضع علامة عليها كوحدة مشتركة.

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

هدفنا هو تحسين كل هذه الأجزاء في نفس الوقت في تطبيق واحد.

حدد Alex Castle طبقة جديدة من تقسيم الحزم (إنشاء ملفات JavaScript منفصلة) تسمح بمزيد من تحسين تجزئة المشترك مع ملفات متعددة وخاصة عند وجود العديد من الصفحات.

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

المجتمع

نحن متحمسون للتغييرات القادمة التي ستؤدي إلى تحسين الأداء في جميع تطبيقات Next.js.

علاوة على ذلك، لا يزال مجتمع Next.js يتوسع:

• كان لدينا أكثر من 800 مساهم قاموا بإضافة على الأقل commit واحد.
• على GitHub، تم تصنيف المشروع أكثر من 41,350 مرة.
• يحتوي مجلد الأمثلة على أكثر من 210 مثالًا.

يضم مجتمع Next.js الآن أكثر من 11,250 عضوًا. انضم إلينا!

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