Backالعودة إلى المدونة

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

يتميز الإصدار 6.1 من Next.js بتحسينات في الموثوقية والاتساق أثناء التطوير

نفخر اليوم بإطلاق الإصدار الجاهز للإنتاج Next.js 6.1 الذي يتضمن:

  • تحسين موثوقية إعادة التحميل السريع (Hot Reloading)
  • تحسينات على قاعدة الكود
  • أدوات تحويل الأكواد (Codemods) لـ Next.js

بالإضافة إلى إصدار Next.js 6.1، يسعدنا الإعلان عن أن موقع nextjs.org أصبح الآن مفتوح المصدر

تحسين موثوقية إعادة التحميل السريع

في الإصدارات السابقة لـ Next.js 6.1، كانت Next.js تستخدم مكتبة react-hot-loader نيابة عن المستخدم. هذه المكتبة تحافظ على حالة React بين عمليات إعادة التحميل السريع.

لكن react-hot-loader تضيف بعض السلوكيات غير القياسية لـ React، على سبيل المثال تتجاهل shouldComponentUpdate ويصبح نوع العنصر مكونًا وكيلًا (Proxy) بدلاً من مكون React الفعلي.

لضمان أن Next.js تكون أقرب ما يمكن إلى React الافتراضي، قمنا بإزالة react-hot-loader كاعتماد، مما يضمن تقارب سلوك وضعي التطوير والإنتاج. لاحظ أن ميزة إعادة التحميل السريع في Next.js لم تتم إزالتها، حيث كانت دائمًا تُدار داخليًا بواسطة Next.js.

إعادة التحميل السريع لأنواع TypeScript والإضافات المخصصة الأخرى

بشكل افتراضي، تبحث Next.js تلقائيًا عن أي ملف .js أو .jsx داخل دليل pages لتحديد المسارات.

مع إدخال webpack الشامل في Next.js 5، أصبح من الممكن وجود صفحات من المستوى العلوي تُترجم إلى js. مثال جيد على ذلك هو TypeScript الذي يستخدم .ts و .tsx.

pageExtensions هو مفتاح تكوين في next.config.js يهدف إلى السماح لإضافات Next.js بتحديد الامتدادات التي يجب اعتبارها كصفحات. على سبيل المثال، @zeit/next-typescript يحدد .ts و .tsx أو @zeit/next-mdx الذي يوثق كيفية وجود صفحات .mdx من المستوى العلوي.

سابقًا، عند تنفيذ pageExtensions، كانت إضافات Next.js مطلوبة لتنفيذ hot-self-accept-loader المستخدم لإعادة التحميل السريع. لم يعد هذا مطلوبًا، حيث عند إضافة امتداد إلى pageExtensions يتم تطبيق hot-self-accept-loader تلقائيًا.

تحسينات على قاعدة الكود

كنا مؤخرًا نمهّد الطريق لميزات قادمة، مما تضمن بعض التغييرات الداخلية التي ستُحسّن جودة الكود على المدى الطويل.

أحد هذه التغييرات هو نقل دليل server/build إلى المستوى العلوي build. هذا يجعل تكوينات webpack و babel أسهل في العثور للمساهمين الجدد.

كنا أيضًا نركز على إضافة أنواع Flow في جميع أنحاء قاعدة الكود.

تغيير أكثر وضوحًا للمستخدمين هو إعادة تسمية .next/dist إلى .next/server. دليل .next يحتفظ بمخرجات البناء. على سبيل المثال عند تشغيل next build ستُخزن النتيجة في .next.

ملفات التصيير المسبق (Pre-rendering) موجودة الآن في دليل server

تم نقل تكرارات الثوابت نفسها إلى ملف مشترك: constants.js

أدوات تحويل الأكواد (Codemods) لـ Next.js

عند إصدار Next.js 6.0، أصبحت الخاصية url التي تُحقن سحريًا في مكونات الصفحة قديمة. سبب إزالة url هو أننا نريد جعل الأمور متوقعة وصريحة جدًا. وجود خاصية url سحرية تظهر من العدم لا يدعم هذا الهدف.

الطريقة الموصى بها للحصول على نفس خصائص url هي استخدام withRouter:

page.js
// قديم
class Page extends React.Component {
  render() {
    const { url } = this.props;
    return <div>{url.pathname}</div>;
  }
}
export default Page;

كيفية الوصول إلى pathname في الإصدارات السابقة لـ Next.js 6 باستخدام url

page.js
// جديد
import { withRouter } from 'next/router';
class Page extends React.Component {
  render() {
    const { router } = this.props;
    return <div>{router.pathname}</div>;
  }
}
export default withRouter(Page);

كيفية الوصول إلى pathname في الإصدارات بعد Next.js 6 باستخدام router المحقون بواسطة withRouter

نظرًا لالتزامنا بجعل مسار الترقية لتطبيقات Next.js بسيطًا، شرعنا في إنشاء طريقة سهلة لترقية استخدامات url إلى withRouter.

نتيجة هذا الجهد هي next‑codemod، وهي مكتبة من أدوات تحويل الأكواد التي تجعل ترقية الميزات القديمة إلى استخداماتها الجديدة سهلة مثل تشغيل أمر واحد.

أول أداة تحويل نقدمها هي url-to-withrouter التي تحول تلقائيًا العديد من الحالات التي استُخدم فيها url إلى withRouter.

Terminal
  jscodeshift -t ./url-to-withrouter.js pages/**/*.js

هذا سيحول استخدامات url إلى withRouter.

اقرأ المزيد هنا

المساهمة في Next.js

مجتمع Next.js ينمو، مع أكثر من 450 مساهمًا قدّموا على الأقل commit واحد في نواة Next.js أو الأمثلة.

هناك العديد من الطرق للمساهمة في Next.js:

موقع nextjs.org مفتوح المصدر

يسعدنا الإعلان أن nextjs.org أصبح الآن مفتوح المصدر ليكون مرجعًا لتنفيذ Nextjs ويمكن تقديم المشكلات/التحسينات مباشرة على المشروع.

المستقبل

نعمل على بعض الميزات الجديدة لزيادة الموثوقية والأداء، إليك أبرز النقاط:

Webpack 4

يأتي Webpack 4 بالكثير من التحسينات: تقسيم أفضل للكود، حاجة أقل للتكوين الافتراضي، والأهم أوقات بناء أسرع. في الاختبارات الأولية التي أجريناها على تطبيق به أكثر من 200 صفحة، انخفض وقت next build من 100 ثانية إلى 70 ثانية في المتوسط. في التشغيل الثاني (مع ذاكرة التخزين المؤقت) استغرق next build 21 ثانية في المتوسط.

Next.js بدون خادم (Serverless)

نجري تغييرات تدريجية للتحضير لنقل next start إلى حزمة خاصة به: next-server. ستكون هذه الحزمة مُحسّنة للغاية من حيث حجم التثبيت ووقت التشغيل. هذه التحسينات ضرورية لحالة الاستخدام "بدون خادم" حيث يتم تنفيذ نسخة جديدة من التطبيق مع كل طلب أو كل بضعة طلبات. مما يعني أن "البدء البارد" للتطبيق يجب أن يكون مُحسّنًا ليكون سريعًا قدر الإمكان.