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

نحن متحمسون اليوم للإعلان عن Next.js 9.3، الذي يتضمن:

دعم توليد المواقع الثابتة من الجيل التالي (SSG): توليد ثابت مُحسّن مدمج من خلال طرق جديدة لجلب البيانات.
وضع المعاينة (Preview Mode): تجاوز الصفحات المُولّدة ثابتًا لعرض المسودات من نظام إدارة المحتوى (CMS).
دعم Sass المدمج لصفحات الأنماط العامة: يمكن للتطبيقات الآن استيراد ملفات .scss مباشرة كصفحات أنماط عامة.
دعم وحدات Sass CSS المدمجة لأنماط مستوى المكون: باستخدام اصطلاح .module.scss، يمكن استيراد CSS محلي النطاق واستخدامه في أي مكان في تطبيقك.
تحسين ثابت تلقائي لصفحة 404: تحسين السرعة والموثوقية من خلال تقديم صفحة 404 بشكل ثابت.
وقت تشغيل أصغر بـ 32 كيلوبايت: حجم وقت تشغيل أصغر لجميع تطبيقات Next.js من خلال تحسينات قوية.
مجتمع Next.js على مناقشات GitHub: يمكنك الآن مناقشة الأسئلة وطرحها مباشرة من مستودع Next.js على GitHub.

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

Terminal

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

دعم توليد المواقع الثابتة من الجيل التالي (SSG)

عند بناء مواقع الويب أو تطبيقات الويب، عادةً ما يتعين عليك الاختيار بين استراتيجيتين: التوليد الثابت (SSG) أو التصيير من جانب الخادم (SSR).

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

قدم Next.js 9.0 مفهوم التحسين الثابت التلقائي. عندما لا تحتوي الصفحة على متطلبات حظر لجلب البيانات مثل getInitialProps، سيتم تصييرها تلقائيًا إلى HTML في وقت البناء.

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

لقد تعاونّا مع مستخدمين كثيفين لـ SSG و next export مثل HashiCorp وناقشنا القيود المناسبة مع المجتمع في طلب التعليقات (RFC) الأكثر تعليقًا في تاريخ Next.js لإنشاء طريقة موحدة جديدة لجلب البيانات والتوليد الثابت.

اليوم، نحن متحمسون جدًا للإعلان عن طريقتين جديدتين لجلب البيانات: getStaticProps و getServerSideProps. كما نقدم طريقة لتوفير معلمات لتوليد صفحات ثابتة لمسارات ديناميكية: getStaticPaths.

هذه الطرق الجديدة لها العديد من المزايا مقارنة بنموذج getInitialProps حيث يوجد تمييز واضح بين ما سيصبح SSG مقابل SSR.

getStaticProps (التوليد الثابت): جلب البيانات في وقت البناء.
getStaticPaths (التوليد الثابت): تحديد المسارات الديناميكية لتقديمها مسبقًا بناءً على البيانات.
getServerSideProps (التصيير من جانب الخادم): جلب البيانات في كل طلب.
هذه التحسينات هي إضافات لواجهة برمجة التطبيقات (API). جميع الوظائف الجديدة متوافقة تمامًا مع الإصدارات السابقة ويمكن تبنيها تدريجيًا. لم يتم تقديم أي إهمالات وسيستمر getInitialProps في العمل كما هو حالياً. نحن نشجع على تبني هذه الطرق الجديدة في الصفحات والمشاريع الجديدة.

getStaticProps

إذا قمت بتصدير دالة غير متزامنة تسمى getStaticProps من صفحة، فإن Next.js سيقوم بتصيير هذه الصفحة مسبقًا في وقت البناء. هذا مفيد بشكل خاص عندما تريد تصيير صفحات ثابتة محددة من نظام إدارة المحتوى (CMS).

تعمل getStaticProps دائمًا في سياق Node.js ويتم تقليل الشجرة (tree-shaken) تلقائيًا من حزم المتصفح، مما يضمن إرسال كود أقل إلى المتصفح. بهذه الطريقة لا داعي للقلق بشأن تنفيذ كود جلب البيانات في كل من بيئتي Node.js والمتصفح، اللتين لديهما بعض التناقضات.

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

pages/posts/[id].js

export async function getStaticProps(context) {
  return {
    props: {}, // سيتم تمريرها إلى مكون الصفحة كخصائص (props)
  };
}

معلمة context هي كائن يحتوي على المفاتيح التالية:

params: يحتوي params على معلمات المسار للصفحات التي تستخدم مسارات ديناميكية. على سبيل المثال، إذا كان اسم الصفحة هو [id].js، فإن params ستبدو مثل { id: ... }. لمعرفة المزيد، راجع توثيق التوجيه الديناميكي. يجب استخدام هذا مع getStaticPaths، والذي سنشرحه لاحقًا.

إليك مثال يستخدم getStaticProps لجلب قائمة من منشورات المدونة من نظام إدارة المحتوى (CMS):

pages/blog.js

// يمكنك استخدام أي مكتبة لجلب البيانات
import fetch from 'node-fetch';
 
// سيتم ملء المنشورات في وقت البناء بواسطة getStaticProps()
function Blog({ posts }) {
  return (
    <ul>
      {posts.map((post) => (
        <li>{post.title}</li>
      ))}
    </ul>
  );
}
 
// يتم استدعاء هذه الدالة في وقت البناء في بيئة Node.js.
// لن يتم استدعاؤها على جانب العميل، لذا يمكنك حتى إجراء
// استعلامات قاعدة بيانات مباشرة. راجع قسم "التفاصيل التقنية".
export async function getStaticProps() {
  // استدعاء نقطة نهاية API خارجية للحصول على المنشورات.
  const res = await fetch('https://.../posts');
  const posts = await res.json();
 
  // من خلال إرجاع { props: posts }، سيستقبل مكون Blog
  // `posts` كخاصية (prop) في وقت البناء
  return {
    props: {
      posts,
    },
  };
}
 
export default Blog;

متى يجب استخدام getStaticProps؟

يجب استخدام getStaticProps إذا:

البيانات المطلوبة لتصيير الصفحة متوفرة في وقت البناء قبل طلب المستخدم.
تأتي البيانات من نظام إدارة محتوى (CMS) بدون واجهة أمامية.
يمكن تخزين البيانات مؤقتًا بشكل عام (وليست خاصة بالمستخدم).
يجب تقديم الصفحة مسبقًا (لتحسين محركات البحث SEO) وتكون سريعة جدًا - حيث يولد getStaticProps ملفات HTML و JSON، وكلاهما يمكن تخزينه مؤقتًا بواسطة CDN لتحسين الأداء.

لمعرفة المزيد عن getStaticProps، راجع توثيق جلب البيانات.

getStaticPaths

إذا كانت الصفحة تحتوي على مسارات ديناميكية وتستخدم getStaticProps، فإنها تحتاج إلى تحديد قائمة بالمسارات التي يجب تصييرها إلى HTML في وقت البناء.

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

pages/posts/[id].js

export async function getStaticPaths() {
  return {
    paths: [
      { params: { ... } } // راجع قسم "paths" أدناه
    ],
    fallback: true or false // راجع قسم "fallback" أدناه
  };
}

مفتاح paths (مطلوب)

يحدد مفتاح paths المسارات التي سيتم تصييرها مسبقًا. على سبيل المثال، افترض أن لديك صفحة تستخدم مسارات ديناميكية باسم pages/posts/[id].js. إذا قمت بتصدير getStaticPaths من هذه الصفحة وأعدت ما يلي لـ paths:

return {
  paths: [
    { params: { id: 1 } },
    { params: { id: 2 } }
  ],
  fallback: ...
}

عندها سيقوم Next.js بتوليد posts/1 و posts/2 بشكل ثابت في وقت البناء باستخدام مكون الصفحة في pages/posts/[id].js.

لاحظ أن القيمة لكل params يجب أن تطابق المعلمات المستخدمة في اسم الصفحة:

إذا كان اسم الصفحة هو pages/posts/[postId]/[commentId]، فإن params يجب أن يحتوي على postId و commentId.
إذا كان اسم الصفحة يستخدم مسارات التقاط الكل، على سبيل المثال pages/[...slug]، فإن params يجب أن يحتوي على slug وهو مصفوفة. على سبيل المثال، إذا كانت هذه المصفوفة هي ['foo', 'bar']، فإن Next.js سيولد الصفحة بشكل ثابت في /foo/bar.

مفتاح fallback (مطلوب)

يجب أن يحتوي الكائن الذي تم إرجاعه بواسطة getStaticPaths على مفتاح fallback منطقي.

Fallback: false

إذا كان fallback هو false، فإن أي مسارات لم يتم إرجاعها بواسطة getStaticPaths ستؤدي إلى صفحة 404. هذا مفيد إذا كنت تعلم أن جميع المسارات ستكون معروفة في وقت البناء.

إليك مثال يقوم بتصيير منشور مدونة واحد لكل صفحة تسمى pages/posts/[id].js. سيتم جلب قائمة منشورات المدونة من نظام إدارة المحتوى (CMS) وإعادتها بواسطة getStaticPaths. ثم، لكل صفحة، يتم جلب بيانات المنشور من نظام إدارة المحتوى باستخدام getStaticProps.

pages/posts/[id].js

import fetch from 'node-fetch';
 
function Post({ post }) {
  // تصيير المنشور...
}
 
// يتم استدعاء هذه الدالة في وقت البناء
export async function getStaticPaths() {
  // استدعاء نقطة نهاية API خارجية للحصول على المنشورات
  const res = await fetch('https://.../posts');
  const posts = await res.json();
 
  // الحصول على المسارات التي نريد تصييرها مسبقًا بناءً على المنشورات
  const paths = posts.map((post) => `/posts/${post.id}`);
 
  // سنقوم بتصيير هذه المسارات فقط في وقت البناء.
  // { fallback: false } يعني أن المسارات الأخرى يجب أن تعرض 404.
  return { paths, fallback: false };
}
 
// يتم استدعاء هذه الدالة أيضًا في وقت البناء
export async function getStaticProps({ params }) {
  // params يحتوي على `id` المنشور.
  // إذا كان المسار مثل /posts/1، فإن params.id هو 1
  const res = await fetch(`https://.../posts/${params.id}`);
  const post = await res.json();
 
  // تمرير بيانات المنشور إلى الصفحة عبر الخصائص (props)
  return { props: { post } };
}
 
export default Post;

Fallback: true

إذا كان fallback هو true، فإن سلوك getStaticProps يتغير، حيث سيقوم Next.js بتصيير المسارات المقدمة إلى HTML في وقت البناء. عندما لا يتم إنشاء مسار في وقت البناء، سيتم إنشاؤه عند الطلب عندما يطلب المستخدم الصفحة.

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

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

مثال على توليد صفحات إضافية بشكل ثابت عند الطلب:

pages/posts/[id].js

import { useRouter } from 'next/router';
import fetch from 'node-fetch';
 
function Post({ post }) {
  const router = useRouter();
 
  // إذا لم يتم إنشاء الصفحة بعد، سيتم عرض هذا
  // في البداية حتى ينتهي تشغيل getStaticProps()
  if (router.isFallback) {
    return <div>جار التحميل...</div>;
  }
 
  // تصيير المنشور...
}
 
// يتم استدعاء هذه الدالة في وقت البناء
export async function getStaticPaths() {
  return {
    // يتم إنشاء `/posts/1` و `/posts/2` فقط في وقت البناء
    paths: [{ params: { id: 1 } }, { params: { id: 2 } }],
    // تمكين توليد صفحات إضافية بشكل ثابت
    // على سبيل المثال: `/posts/3`
    fallback: true,
  };
}
 
// يتم استدعاء هذه الدالة أيضًا في وقت البناء
export async function getStaticProps({ params }) {
  // params يحتوي على `id` المنشور.
  // إذا كان المسار مثل /posts/1، فإن params.id هو 1
  const res = await fetch(`https://.../posts/${params.id}`);
  const post = await res.json();
 
  // تمرير بيانات المنشور إلى الصفحة عبر الخصائص (props)
  return { props: { post } };
}
 
export default Post;

لمعرفة المزيد عن getStaticPaths، راجع توثيق جلب البيانات.

getServerSideProps

إذا قمت بتصدير دالة async تُسمى getServerSideProps من صفحة، فإن Next.js سيقوم بعرض هذه الصفحة عند كل طلب (SSR - العرض من جانب الخادم).

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

هذا يسمح لك باستخدام أي تقنية لجلب البيانات سواء كانت غير متزامنة أو حتى متزامنة، بما في ذلك fetch، REST، GraphQL، أو حتى الوصول المباشر إلى قاعدة بيانات.

عند التنقل بين الصفحات باستخدام next/link بدلاً من تنفيذ getServerSideProps في المتصفح، سيقوم Next.js بإجراء طلب إلى الخادم والذي سيعيد نتيجة استدعاء getServerSideProps.

pages/index.js

export async function getServerSideProps(context) {
  return {
    props: {}, // سيتم تمريرها إلى مكون الصفحة كـ props
  };
}

معامل context هو كائن يحتوي على المفاتيح التالية:

params: إذا كانت هذه الصفحة تستخدم مسارًا ديناميكيًا، فإن params يحتوي على معلمات المسار. إذا كان اسم الصفحة هو [id].js، فإن params سيبدو كـ { id: ... }. لمعرفة المزيد، راجع توثيق المسارات الديناميكية.
req: كائن طلب HTTP.
res: كائن استجابة HTTP.
query: سلسلة الاستعلام.

إليك مثالاً يستخدم getServerSideProps لجلب البيانات عند وقت الطلب وعرضها:

pages/index.js

function Page({ data }) {
  // عرض البيانات...
}
 
// يتم استدعاء هذه الدالة عند كل طلب
export async function getServerSideProps() {
  // جلب البيانات من واجهة برمجة التطبيقات الخارجية
  const res = await fetch(`https://.../data`);
  const data = await res.json();
 
  // تمرير البيانات إلى الصفحة عبر props
  return { props: { data } };
}
 
export default Page;

لمعرفة المزيد عن getServerSideProps، راجع توثيق جلب البيانات.

وضع المعاينة

كما ناقشنا سابقًا في هذا المنشور، فإن التوليد الثابت (Static Generation) مفيد عندما تقوم صفحاتك بجلب البيانات من نظام إدارة المحتوى (CMS). ومع ذلك، فهو ليس مثاليًا عندما تكتب مسودة على نظام إدارة المحتوى الخاص بك وتريد معاينة المسودة فورًا على صفحتك. نظرًا لأن المخرجات ثابتة، تصبح معاينة التغييرات أصعب حيث سيتعين عليك إعادة توليد تلك الصفحة الثابتة.

يقدم getStaticProps في Next.js إمكانيات جديدة مثل الاستفادة من قدرات Next.js في العرض عند الطلب تحت ظروف معينة.

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

يسعدنا الإعلان عن ميزة جديدة مدمجة في Next.js لتلبية هذه الحاجة: وضع المعاينة.

يسمح وضع المعاينة للمستخدمين بتجاوز الصفحة المولدة ثابتًا لعرض صفحة مسودة عند الطلب (SSR) من نظام إدارة المحتوى على سبيل المثال.

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

وضع المعاينة متاح بالفعل عند استخدام next start، أو بسلاسة عن طريق النشر على شبكة Vercel Edge.

جرب وضع المعاينة بنفسك على https://next-preview.vercel.app/

تعرف على المزيد حول وضع المعاينة من خلال الرجوع إلى التوثيق.

التعاون مع مزودي أنظمة إدارة المحتوى

يسمح لك getStaticProps بجلب البيانات من أي مصدر بيانات، بما في ذلك أنظمة إدارة المحتوى.

نحن نتعاون بنشاط مع العديد من اللاعبين الرئيسيين في نظام إدارة المحتوى لتوفير أمثلة وإرشادات حول التكامل مع Next.js.

تشمل الأمثلة التي يتم العمل عليها حاليًا:

إذا كانت شركتك نشطة في نظام إدارة المحتوى، فنحن نود العمل معك! لا تتردد في التواصل مع فريقنا عبر البريد الإلكتروني أو تويتر.

دعم Sass المدمج لملفات الأنماط العامة

قدم Next.js 9.2 دعمًا مدمجًا لملفات أنماط CSS العامة لاستبدال ملحق next-css بإعدادات افتراضية أفضل لتوفير نتيجة أكثر تحسينًا.

بعد الإصدار مباشرة، تلقينا طلبات متزايدة لدمج دعم Sass حيث أن العديد من الشركات التي تنتقل إلى Next.js لديها نظام تصميم قائم على Sass.

عند التحقق من استخدام ملحقات Next.js، وجدنا أن حوالي 30% من تطبيقات Next.js تستخدم next-sass اليوم. مقارنة بـ 44% يستخدمون CSS عادي و6% يستخدمون Less.

علاوة على ذلك، كان next-sass يفتقد إلى نفس القيود مثل next-css. مما يعني أنه يمكنك استيراد ملف Sass في كل ملف من المشروع، ومع ذلك، سيكون ملف Sass هذا عامًا للتطبيق بأكمله.

بعد النظر في هذه الإحصاءات والملاحظات، يسعدنا الإعلان عن أن Next.js يدعم الآن استيراد ملفات أنماط Sass مدمجًا.

للبدء في استخدام استيرادات Sass العامة في تطبيقك، قم بتثبيت sass:

Terminal

npm install sass

ثم، استورد ملف Sass داخل pages/_app.js.

على سبيل المثال، ضع في الاعتبار ملف الأنماط التالي المسمى styles.scss في جذر مشروعك:

$primary-color: #333;
 
body {
  padding: 20px 20px 60px;
  margin: 0;
  color: $primary-color;
}

قم بإنشاء ملف pages/_app.js إذا لم يكن موجودًا بالفعل. ثم، استورد ملف styles.scss:

pages/_app.js

import '../styles.scss';
 
// هذا التصدير الافتراضي مطلوب في ملف `pages/_app.js` جديد.
export default function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />;
}

نظرًا لأن ملفات الأنماط عامة بطبيعتها، يجب استيرادها في مكون <App> المخصص. هذا ضروري لتجنب تعارضات أسماء الفئات وترتيبها للأنماط العامة.

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

في وضع الإنتاج، سيتم دمج جميع ملفات Sass وCSS تلقائيًا في ملف .css مضغوط واحد. سيتم تحميل ملف CSS هذا عبر علامة <link> وحقنه تلقائيًا في ترميز HTML الافتراضي الذي يولده Next.js.

هذه الميزة الجديدة متوافقة تمامًا مع الإصدارات السابقة. إذا كنت تستخدم @zeit/next-sass أو أي ملحقات أخرى متعلقة بـ CSS، فسيتم تعطيل الميزة لتجنب التعارضات.

إذا كنت تستخدم حاليًا @zeit/next-sass، نوصي بإزالة الملحق من next.config.js و package.json، وبالتالي الانتقال إلى دعم Sass المدمج عند الترقية.

دعم Sass CSS Modules المدمج لأنماط مستوى المكون

يدعم Next.js الآن CSS Modules مع ملفات Sass باستخدام اصطلاح تسمية الملف [name].module.scss.

على عكس الدعم المتاح سابقًا في Next.js 5+ باستخدام next-sass، يمكن الآن لـ Sass العام ووحدات CSS التعايش - حيث كان next-sass يتطلب معالجة جميع ملفات .scss في تطبيقك إما كملفات عامة أو محلية، ولكن ليس كليهما.

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

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

للبدء في استخدام وحدات Sass CSS في تطبيقك، تأكد من تثبيت sass:

Terminal

npm install sass

الآن، ضع في الاعتبار مكون Button القابل لإعادة الاستخدام في مجلد components/:

أولاً، أنشئ components/Button.module.scss بالمحتوى التالي:

/*
لا داعي للقلق بشأن تعارض .error {} مع أي ملفات `.css` أو
`.module.css` أخرى!
*/
$color: white;
 
.error {
  color: $color;
  background-color: red;
}

ثم، أنشئ components/Button.js، وقم باستيراد واستخدام ملف CSS أعلاه:

components/Button.js

import styles from './Button.module.scss';
 
export function Button() {
  return (
    <button
      type="button"
      // لاحظ كيف يتم الوصول إلى فئة "error" كخاصية على كائن
      // `styles` المستورد.
      className={styles.error}
    >
      Destroy
    </button>
  );
}

وحدات CSS لملفات Sass هي ميزة اختيارية ولا يتم تمكينها إلا للملفات ذات الامتداد .module.scss. لا يزال يتم دعم ملفات الأنماط العامة وأنماط Sass العامة.

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

كما هو مذكور أعلاه، هذه الميزة الجديدة متوافقة تمامًا مع الإصدارات السابقة. إذا كنت تستخدم @zeit/next-sass أو أي ملحقات أخرى متعلقة بـ CSS، فسيتم تعطيل الميزة لتجنب التعارضات.

إذا كنت تستخدم حاليًا @zeit/next-sass، نوصي بإزالة الملحق من next.config.js و package.json، وبالتالي الانتقال إلى دعم Sass المدمج.

التحسين الثابت التلقائي لصفحة 404

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

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

لقد سعينا لوضعك في مسار النجاح بطريقتين:

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

هذه الميزة متوافقة تمامًا مع الإصدارات السابقة، لذا إذا كان لديك حاليًا pages/_error.js مخصص، فسيتم استخدامه لصفحة 404 حتى تقوم بإضافة pages/404.js.

صفحة 404 ثابتة افتراضيًا

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

صفحة 404 مخصصة باستخدام pages/404.js

للتجاوز عن صفحة 404 الافتراضية، يمكنك الآن إنشاء pages/404.js والتي ستظل محسنة ثابتًا تلقائيًا في وقت البناء. يتم استخدام هذه الصفحة بدلاً من pages/_error.js لعرض 404 إذا كان تطبيقك يحتوي على واحدة.

pages/404.js

export default () => <h1>هذه هي صفحة 404</h1>;

32+ كيلوبايت أصغر وقت تشغيل (15 كيلوبايت+ مضغوط)

يدعم Next.js نفس المتصفحات التي يدعمها React نفسه، دون الحاجة إلى أي تكوين. وهذا يشمل Internet Explorer 11 (IE11) وجميع المتصفحات الشائعة (Edge، Firefox، Chrome، Safari، Opera، وغيرها).

كجزء من هذا التوافق، نقوم أيضًا بتحويل تطبيقك ليكون متوافقًا مع IE11: هذا يسمح لك باستخدام ميزات ES6+، Async/Await، خصائص Object Rest/Spread، والمزيد — كل ذلك دون الحاجة إلى أي تكوين.

جزء من عملية التحويل هذه يتضمن أيضًا حقن polyfills المطلوبة بشكل شفاف (مثل Array.from أو Symbol). ومع ذلك، هذه الـ polyfills ضرورية فقط لأقل من 10% من حركة المرور على الويب، في معظم الحالات لدعم IE11.

بدءًا من Next.js 9.3، سيقوم Next.js تلقائيًا بتحميل الـ polyfills اللازمة لدعم المتصفحات القديمة، وسيقوم بتحميل الـ polyfills فقط في هذه المتصفحات القديمة.

عمليًا، هذا يعني أن 32 كيلوبايت أو أكثر سيتم إزالتها من حجم الحمل الأول لـ 90%+ من مستخدميك.

هذه التوفيرات في الحجم أكبر حتى للتطبيقات الأكبر التي تعتمد على ميزات متصفح أكثر.

هذا التحسين تلقائي بالكامل ولا توجد حاجة إلى أي تغييرات في التطبيق للاستفادة منه!

المجتمع

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

لدينا أكثر من 927 مساهم مستقل.
على GitHub، تم وضع علامة نجمية على المشروع أكثر من 46,600 مرة.
يحتوي دليل الأمثلة على أكثر من 226 مثالًا.

يضم مجتمع Next.js الآن أكثر من 15,250 عضوًا. يمكن الآن العثور على المجتمع على مناقشات GitHub، مكان جديد للمجتمع لمناقشة وطرح الأسئلة! انضم إلينا!

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

شكر خاص لـ Jeff Escalante للملاحظات القيمة على طرق جلب البيانات الجديدة.

شكرًا كبيرًا لكل من ساهم في هذا الإصدار: @arcanis، @lgordey، @ijjk، @martpie، @jaywink، @fabianishere، @dijs، @TheRusskiy، @quinnturner، @timneutkens، @lfades، @vvo، @adithwip، @rafaelalmeidatk، @bmathews، @Spy-Seth، @EvgeniyKumachev، @chibicode، @piglovesyou، @HaNdTriX، @Timer، @janicklas-ralph، @devknoll، @prateekbh، @ethanryan، @MoOx، @rifaidev، @msweeneydev، @motiko، و @balazsorban44 للمساعدة!