نحن متحمسون اليوم للإعلان عن Next.js 9.2 الذي يتضمن:
- دعم CSS المدمج لملفات الأنماط العامة: يمكن للتطبيقات الآن استيراد ملفات
.css
مباشرة كملفات أنماط عامة. - دعم وحدات CSS المدمج للأنماط على مستوى المكون: باستخدام اصطلاح
.module.css
، يمكن استيراد CSS محلي النطاق واستخدامه في أي مكان في تطبيقك. - استراتيجية محسنة لتقسيم الشفرة: قام فريق Google Chrome بتحسين استراتيجية تقسيم الشفرة في Next.js بشكل كبير، مما أدى إلى حزم عميل أصغر حجمًا بكثير. علاوة على ذلك، قاموا بزيادة استخدام HTTP/2 لتحسين سرعة تحميل الصفحة دون الإضرار بأداء HTTP/1.1.
- مسارات ديناميكية شاملة: تدعم المسارات الديناميكية في Next.js الآن المسارات الشاملة، مما يدعم مجموعة متنوعة من حالات الاستخدام الجديدة، مثل المواقع المدعومة بنظام إدارة المحتوى (CMS).
جميع هذه الميزات غير متعارضة مع الإصدارات السابقة ومتوافقة معها تمامًا. كل ما تحتاجه للتحديث هو تشغيل:
npm i next@latest react@latest react-dom@latest
دعم CSS المدمج لملفات الأنماط العامة
قدم Next.js 5 دعمًا لاستيراد CSS من خلال ملحق مخصص يسمى next-css
والذي وسع سلوك Next.js.
مع مرور الوقت، تلقينا ملاحظات متسقة من الشركات والمستخدمين لـ Next.js، تشير إلى أنهم غالبًا ما يضيفون next-css
إلى تطبيقاتهم.
علاوة على ذلك، كان لدى next-css
بعض القيود المفقودة عند استيراد CSS. على سبيل المثال، يمكنك استيراد ملف CSS في كل ملف من المشروع، ولكن هذا الملف المستورد سيكون عالميًا للتطبيق بأكمله.
لتحسين تجربة المطور وحل هذه التناقضات، بدأنا العمل على دمج دعم استيراد CSS في Next.js افتراضيًا.
نحن متحمسون للإعلان عن أن Next.js يدعم الآن بشكل أصلي استيراد ملفات الأنماط إلى تطبيقك.
للبدء في استخدام استيراد CSS في تطبيقك، قم باستيراد ملف CSS داخل pages/_app.js
.
على سبيل المثال، ضع في الاعتبار ملف الأنماط التالي المسمى styles.css
في جذر مشروعك:
body {
padding: 20px 20px 60px;
margin: 0;
}
قم بإنشاء ملف pages/_app.js
إذا لم يكن موجودًا بالفعل.
ثم، استورد ملف styles.css
:
import '../styles.css';
// هذا التصدير الافتراضي مطلوب في ملف `pages/_app.js` جديد.
export default function MyApp({ Component, pageProps }) {
return <Component {...pageProps} />;
}
نظرًا لأن ملفات الأنماط عالمية بطبيعتها، يجب استيرادها في مكون <App>
المخصص. هذا ضروري لتجنب تعارضات أسماء الفئات وترتيبها للأنماط العالمية.
في وضع التطوير، يسمح التعبير عن ملفات الأنماط بهذه الطريقة بتحديث الأنماط تلقائيًا على الصفحة أثناء تحريرها.
في وضع الإنتاج، سيتم دمج جميع ملفات CSS تلقائيًا في ملف .css
واحد مضغوط. سيتم تحميل ملف CSS هذا عبر علامة <link>
وحقنه تلقائيًا في ترميز HTML الافتراضي الذي يولده Next.js.
هذه الميزة الجديدة متوافقة تمامًا مع الإصدارات السابقة. إذا كنت تستخدم @zeit/next-css
أو أي ملحقات أخرى متعلقة بـ CSS، فسيتم تعطيل الميزة لتجنب التعارضات.
إذا كنت تستخدم حاليًا @zeit/next-css
، نوصي بإزالة الملحق من next.config.js
و package.json
، وبالتالي الانتقال إلى دعم CSS المدمج عند الترقية.
دعم وحدات CSS المدمج للأنماط على مستوى المكون
يدعم Next.js الآن وحدات CSS باستخدام اصطلاح تسمية الملفات [name].module.css
.
على عكس الدعم المتاح سابقًا في Next.js 5 باستخدام next-css
، يمكن الآن لـ CSS العالمي ووحدات CSS التعايش — حيث كان next-css
يتطلب معالجة جميع ملفات .css
في تطبيقك كعالمية أو محلية، ولكن ليس كليهما.
تقوم وحدات CSS بتحديد نطاق CSS محليًا عن طريق إنشاء أسماء فئات فريدة تلقائيًا. هذا يسمح لك باستخدام نفس اسم فئة CSS في ملفات مختلفة دون القلق بشأن التعارضات.
هذا السلوك يجعل وحدات CSS الطريقة المثالية لتضمين CSS على مستوى المكون. يمكن استيراد ملفات وحدات CSS في أي مكان في تطبيقك.
على سبيل المثال، ضع في الاعتبار مكون Button
قابل لإعادة الاستخدام في مجلد components/
:
أولاً، أنشئ components/Button.module.css
بالمحتوى التالي:
/*
لا داعي للقلق بشأن تعارض .error {} مع أي ملفات `.css` أو
`.module.css` أخرى!
*/
.error {
color: white;
background-color: red;
}
ثم، أنشئ components/Button.js
، وقم باستيراد واستخدام ملف CSS أعلاه:
import styles from './Button.module.css';
export function Button() {
return (
<button
type="button"
// لاحظ كيف يتم الوصول إلى فئة "error" كخاصية على كائن
// `styles` المستورد.
className={styles.error}
>
Destroy
</button>
);
}
وحدات CSS هي ميزة اختيارية ولا يتم تمكينها إلا للملفات ذات امتداد .module.css
. لا يزال دعم ملفات الأنماط العادية <link>
وملفات CSS العامة متاحًا.
في وضع الإنتاج، يتم دمج جميع ملفات وحدات CSS تلقائيًا في العديد من ملفات .css
مضغوطة ومقسمة حسب الشفرة. تمثل ملفات .css
هذه مسارات تنفيذ ساخنة في تطبيقك، مما يضمن تحميل الحد الأدنى من CSS لكل صفحة لتطبيقك للرسم.
كما هو مذكور أعلاه، هذه الميزة الجديدة متوافقة تمامًا مع الإصدارات السابقة. إذا كنت تستخدم @zeit/next-css
أو أي ملحقات أخرى متعلقة بـ CSS، فسيتم تعطيل الميزة لتجنب التعارضات.
إذا كنت تستخدم حاليًا @zeit/next-css
، نوصي بإزالة الملحق من next.config.js
و package.json
، وبالتالي الانتقال إلى دعم CSS المدمج.
استراتيجية محسنة لتقسيم الشفرة
كانت إصدارات Next.js السابقة للإصدار 9.2 تحتوي على مجموعة ثابتة من حزم JavaScript المطلوبة لتحميل الصفحة وجعلها تفاعلية:
- ملف JavaScript الخاص بالصفحة
- ملف يحتوي على JavaScript المشترك
- حزمة وقت تشغيل Next.js من جانب العميل
- حزمة وقت تشغيل Webpack من جانب العميل
- عمليات الاستيراد الديناميكية (المضافة عبر
next/dynamic
، عند استخدامها)
لجعل الصفحة تفاعلية، يجب تحميل جميع هذه الحزم لأنها تعتمد على بعضها البعض لبدء تشغيل React في المتصفح.
نظرًا لأن جميع هذه الحزم مطلوبة لتصبح التطبيق تفاعليًا، فمن المهم أن تكون مُحسنة قدر الإمكان. عمليًا، هذا يعني عدم تنزيل كود إضافي من أجزاء أخرى من التطبيق.
لهذا السبب، استخدم Next.js حزمة commons
التي احتوت على JavaScript المشترك بين الصفحات. كان حساب استراتيجية تقسيم الحزم القديمة لتوليد commons
يعتمد على نسبة استخدام إرشادية. إذا تم استخدام وحدة في أكثر من 50% من جميع الصفحات، فسيتم وضع علامة عليها كوحدة مشتركة. وإلا، فسيتم تجميعها في ملف JavaScript الخاص بالصفحة.
ومع ذلك، يمكن أن تتكون التطبيقات من العديد من أنواع الصفحات المختلفة. على سبيل المثال، صفحات تسويقية، مدونة، ولوحة تحكم. إذا كان هناك عدد كبير من الصفحات التسويقية مقارنة بأنواع الصفحات الأخرى، فسيؤدي حساب المشترك إلى تحسينات تركز بشدة على الصفحات التسويقية.
هدفنا هو تحسين جميع أنواع الصفحات، في تطبيق واحد.
اقترح أليكس كاسل طريقة جديدة لتقسيم الحزم (إنشاء ملفات JavaScript منفصلة) تتيح تحسين تجزئة المشترك مع ملفات متعددة، بما في ذلك عند وجود العديد من أنواع الصفحات.
اليوم، يسعدنا الإعلان عن أن هذا السلوك الجديد لتقسيم الحزم مفعل افتراضيًا في Next.js 9.2. نود أن نعرب عن امتناننا العميق لفريق Google Chrome وأليكس كاسل للمساهمة بهذا التغيير. يعكس هذا التغيير الجهد التراكمي لأسابيع من البحث والاختبار المعملي واختبار العالم الحقيقي والتنفيذ.
يستفيد تنفيذ تقسيم الحزم الجديد من HTTP/2 لتقديم عدد أكبر من الحزم الأصغر حجمًا.
وفقًا للإرشاد الجديد، يتم إنشاء الحزم لـ:
- حزمة صغيرة لكل صفحة.
- حزمة إطار عمل تحتوي على React، ReactDOM، Scheduler الخاص بـ React، إلخ.
- حزم مكتبات لأي تبعية
node_module
تزيد عن 160 كيلوبايت (قبل الضغط/التصغير) - حزمة مشتركة للكود المستخدم عبر جميع الصفحات.
- أكبر عدد ممكن من الحزم المشتركة (المستخدمة بواسطة صفحتين أو أكثر)، مع التحسين للحجم الكلي للتطبيق وسرعة التحميل الأولية.
- وقت تشغيل Next.js من جانب العميل.
- وقت تشغيل Webpack.
لنلقي نظرة على ما يعنيه هذا في تطبيق واقعي:
شريك صناعي مبكر التبني، Barnebys®، شهد انخفاضًا بنسبة 23% في الحجم الكلي للتطبيق.
علاوة على ذلك، تم تقليل أكبر حزمة JS لديهم بنسبة 30% — من 605 كيلوبايت إلى 425 كيلوبايت — دون الحاجة إلى أي تغييرات في الكود.
شريك صناعي آخر، SumUp®، شهد انخفاضًا بنسبة 70% في أكبر حزمة JS لديهم — من 395 كيلوبايت إلى 122 كيلوبايت — دون الحاجة إلى أي تغييرات في الكود.
أكبر حزمة JavaScript
قبل | بعد | الفرق | |
---|---|---|---|
Barnebys | 605 كيلوبايت | 425 كيلوبايت | أصغر بنسبة 30% |
SumUp | 395 كيلوبايت | 122 كيلوبايت | أصغر بنسبة 70% |
لا يقلل سلوك تقسيم الحزم الجديد من الحجم الكلي وحجم التحميل الأولي فحسب، بل أيضًا من عمليات التنقل من جانب العميل المتعاقبة. شهدت Barnebys® انخفاضًا بنسبة 87% في كمية JavaScript المحملة بعد ستة (6) عمليات تنقل بين الصفحات:
JavaScript المحمل بواسطة عمليات انتقال متعددة من جانب العميل
قبل | بعد | الفرق | |
---|---|---|---|
Barnebys | 136 كيلوبايت | 18 كيلوبايت | أصغر بنسبة 87% |
هذا السلوك الجديد متوافق تمامًا مع الإصدارات السابقة. كل ما تحتاجه للاستفادة من تحسين الأداء هذا هو الترقية إلى أحدث إصدار من Next.js.
مسارات ديناميكية شاملة
مع إصدار Next.js 9، قدمنا شرائح المسار الديناميكي بهدف تبسيط الأجزاء الديناميكية في Next.js دون الحاجة إلى خادم مخصص. تم تبني هذه الميزة بشكل كبير من قبل مستخدمي Next.js.
كانت هناك بعض الحالات التي لم تغطيها ميزة شرائح المسار الديناميكي.
إحدى هذه الحالات كانت المسارات الشاملة. على سبيل المثال، توجيه مسار شامل مثل /post/**
كصفحة. هذا مفيد بشكل خاص عندما يكون لديك بنية متداخلة يتم تعريفها بواسطة مصدر محتوى مثل نظام إدارة المحتوى (CMS).
يمكنك الآن إنشاء مسارات ديناميكية شاملة باستخدام صيغة [...name]
.
على سبيل المثال، pages/post/[...slug].js
سيطابق /post/a
، /post/a/b
، /post/a/b/c
، وهكذا.
سيتم توفير slug
في كائن استعلام الموجه كمصفوفة من أجزاء المسار الفردية. لذا، للمسار /post/foo/bar
، سيكون كائن الاستعلام { slug: ['foo', 'bar'] }
.
المجتمع
نحن متحمسون جدًا لرؤية النمو المستمر في اعتماد Next.js:
- لدينا أكثر من 880 مساهمًا مستقلًا.
- على GitHub، حصل المشروع على أكثر من 44,000 نجمة.
- يحتوي دليل الأمثلة على أكثر من 220 مثالًا.
يضم مجتمع Next.js الآن أكثر من 13,800 عضو. انضم إلينا!
نحن ممتنون لمجتمعنا وجميع الملاحظات والمساهمات الخارجية التي ساعدت في تشكيل هذا الإصدار.