Next.js 9 |Next.js

پس از 70 نسخه Canary، ما خوشحالیم که Next.js 9 را معرفی می کنیم که شامل:
- پشتیبانی داخلی Zero-Config TypeScript: به لطف پشتیبانی خودکار TypeScript و بررسی نوع یکپارچه، برنامه خود را با اطمینان بیشتر بسازید.
- مسیریابی پویا مبتنی بر سیستم فایل: الزامات پیچیده مسیریابی برنامه را در سراسر سیستم فایل بدون نیاز به سرور سفارشی بیان کنید.
- بهینه سازی استاتیک خودکار: وب سایت های فوق سریع بسازید که سودمند باشند رندر سمت سرور و پیش رندر استاتیک به طور پیش فرض بدون به خطر انداختن ویژگی ها.
- مسیرهای API: با استفاده از بارگذاری مجدد داغ و خط لوله ساخت یکپارچه، به سرعت نقاط پایانی برنامه های کاربردی را بسازید.
- بهینه سازی تولید بیشتر: به لطف واکشی پیشنمایش و سایر بهینهسازیها، برنامهها بیشتر از همیشه پاسخگو هستند.
- DX بهبود یافته: پیشرفت های محجوب و آسان برای کمک به شما برای توسعه بهترین حالت.
مانند همیشه، ما در تلاش هستیم تا اطمینان حاصل کنیم که همه این مزایا با هم سازگار هستند. برای اکثر برنامه های Next.js، تنها کاری که باید انجام دهید این است که:
npm i next@latest react@latest react-dom@latest
موارد بسیار کمی وجود دارد که پایگاه کد شما نیاز به تغییرات داشته باشد. برای اطلاعات بیشتر به راهنمای ارتقا مراجعه کنید.
از زمان آخرین شماره ما، ما از دیدن شرکت هایی مانند IGN، Bang & Olufsen، Intercom، Buffer و Ferrari با Next.js بسیار خوشحالیم. برای اطلاعات بیشتر، ویترین را ببینید!
یک سال پیش، 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 CLI شما را در نصب انواع React و Node.js راهنمایی می کند.
Next.js نیز یک مقدار پیش فرض ایجاد می کند tsconfig.json با تنظیمات پیش فرض معقول اگر از قبل در دسترس نباشند. این فایل بررسی نوع یکپارچه را در ویرایشگرهایی مانند کد ویژوال استودیو فعال می کند.
لینک را به عنوان کپی کنیدبررسی نوع یکپارچه
Next.js بررسی نوع را برای شما در ساختهای توسعه و تولید انجام میدهد.
در حین توسعه، Next.js پس از ذخیره یک فایل، خطاهای ورودی را به شما نشان می دهد. بررسی تایپ در پسزمینه انجام میشود و به شما این امکان را میدهد که فوراً با برنامه بهروزرسانی شده خود در مرورگر تعامل داشته باشید. اشتباهات تایپی پس از در دسترس قرار گرفتن در مرورگر منتشر می شود.
Next.js همچنین به طور خودکار در ساخت تولید شکست خواهد خورد (یعنی next build) در صورت وجود اشتباهات املایی این به جلوگیری از ارسال کد شکسته به تولید کمک می کند.
لینک را به عنوان کپی کنیدهسته Next.js که با TypeScript نوشته شده است
در چند ماه گذشته ما بیشتر کدهای پایه را به TypeScript منتقل کردهایم، این نه تنها کیفیت کد ما را بهبود بخشیده است، بلکه به ما امکان میدهد تا انواع ماژولهای اصلی را نیز ارائه کنیم.
مثلا وقتی وارد می کنید next/link، ویرایشگرهایی که از TypeScript پشتیبانی می کنند ویژگی های مجاز و مقادیری را که می پذیرند را نشان می دهند.

مسیریابی پویا (همچنین به عنوان URL Slugs یا Pretty/Clean URL شناخته می شود) یکی از اولین درخواست های ویژگی GitHub از زمان انتشار Next.js در 2.5 سال پیش بود!
مشکل در Next.js 2.0 با معرفی API سرور سفارشی برای استفاده از Next.js به صورت برنامهریزی حل شد. این اجازه می دهد تا Next.js به عنوان یک موتور رندر مورد استفاده قرار گیرد و به انتزاع و نقشه برداری از URL های ورودی برای ارائه صفحات خاصی اجازه دهد.
ما با کاربران صحبت کردیم و در مورد بسیاری از برنامه های آنها تحقیق کردیم و متوجه شدیم که بسیاری از آنها یک سرور سفارشی دارند. الگویی ظاهر شد: مهمترین دلیل برای سرور سفارشی، مسیریابی پویا بود.
با این حال، یک سرور سفارشی با مشکلات خاص خود همراه است: مسیریابی به جای پروکسی در سطح سرور انجام می شود، به صورت یکپارچه مستقر و مقیاس بندی می شود و مستعد مشکلات عملکرد است.
از آنجا که یک سرور سفارشی نیاز دارد که کل برنامه در یک نمونه در دسترس باشد، معمولاً پیاده سازی آن در یک محیط بدون سرور که این مشکلات را حل می کند دشوار است. درخواستهای بدون سرور به لایه پروکسی هدایت میشوند و بهطور مستقل مقیاس/اجرا میشوند تا از مشکلات عملکرد جلوگیری شود.
ما همچنین معتقدیم که می توانیم تجربه توسعه دهنده بهتری را ارائه دهیم! بسیاری از جادوی Next.js زمانی شروع می شود که شما یک فایل با نام ایجاد می کنید pages/blog.js و ناگهان صفحه ای در دسترس دارید /blog.
چرا کاربر باید سرور خود را ایجاد کند و در مورد API برنامه نویسی Next.js برای پشتیبانی از مسیری مانند یاد بگیرد /blog/my-first-post (/blog/:id)؟
بر اساس این بازخورد و چشم انداز، ما شروع به کاوش راه حل های نقشه برداری مسیر کردیم که توسط کاربران قبلاً می دانستند: pages/ اشاره گر
لینک را به عنوان کپی کنیدیک صفحه مسیریابی پویا ایجاد کنید
Next.js از ایجاد مسیرها با پارامترهای نامگذاری اولیه پشتیبانی میکند، الگویی که توسط آن رایج شده است path-to-regexp (کتابخانه ای که اکسپرس را تامین می کند).
صفحه ای ایجاد کنید که با مسیر مطابقت داشته باشد /post/:pid اکنون می توان با ایجاد یک فایل در خود به دست آورد pages دایرکتوری به نام: pages/post/[pid].js!
Next.js به طور خودکار به درخواست هایی مانند پاسخ می دهد /post/1، /post/hello-nextjsو غیره و رندر صفحه تعریف شده در pages/post/[pid].js. بخش URL منطبق به عنوان پارامتر درخواست با نام مشخص شده بین صفحه شما ارسال می شود [square-brackets].
به عنوان مثال: با توجه به صفحه زیر و پرس و جو /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 یا بخش Learn about Next.js بخوانید.
Next.js پشتیبانی از تولید وب سایت استاتیک را در نسخه 3 اضافه کرد که حدود دو سال پیش منتشر شد. در آن زمان، این ویژگی بیشترین درخواست برای افزودن به Next.js بود.
و دلیل خوبی دارد: نمی توان انکار کرد که وب سایت های ایستا هستند سریع آنها نیازی به محاسبات سمت سرور ندارند و میتوانند فوراً از مکانهای CDN برای کاربر نهایی پخش شوند.
با این حال، انتخاب بین یک برنامه ارائه شده در سمت سرور یا برنامه ایستا تولید شده باینری بود، شما رندر سمت سرور یا تولید استاتیک را انتخاب می کنید. موقعیت وسطی وجود نداشت.
در واقع، برنامه ها ممکن است نیازهای متفاوتی داشته باشند. این الزامات نیازمند استراتژیهای رندرینگ و مبادلات متفاوتی است.
به عنوان مثال، صفحه اصلی و صفحات بازاریابی معمولا حاوی محتوای ثابت هستند و کاندیدای عالی برای بهینه سازی استاتیک هستند.
از سوی دیگر، داشبورد محصول می تواند از رندر سمت سرور که در آن داده ها به طور مکرر به روز می شوند، بهره مند شود.
ما شروع به تحقیق کردیم که چگونه میتوانیم بهترینها را در هر دو دنیا به مصرفکنندگان بدهیم به صورت پیش فرض سریع. چگونه میتوانیم صفحات بازاریابی ثابت و صفحات رندر شده توسط سرور پویا را در اختیار کاربران قرار دهیم؟
با شروع با Next.js 9، کاربران دیگر مجبور نیستند بین رندر کامل سرور یا صادرات استاتیک برنامه خود یکی را انتخاب کنند. برای هر صفحه بهترین های هر دو دنیا را به شما می دهد.
لینک را به عنوان کپی کنیدصادرات استاتیک جزئی خودکار
یک اکتشافی برای تعیین خودکار اینکه آیا یک صفحه میتواند در HTML ایستا از قبل ارائه شود یا خیر، معرفی شد.
این تعیین با توجه به اینکه آیا صفحه دارای الزامات مسدود کردن دادهها بر اساس استفاده است یا خیر، تعیین میشود getInitialProps.
این اکتشافی به Next.js اجازه میدهد تا برنامههای ترکیبی که حاوی آن هستند را پخش کند هم صفحات رندر شده توسط سرور و هم صفحات تولید شده به صورت ایستا.
سرور داخلی Next.js (next start) و API برنامه نویسی (app.getRequestHandler()) هر دو از این خروجی ساخت پشتیبانی می کنند شفاف. هیچ پیکربندی یا پردازش خاصی مورد نیاز نیست.
صفحات ایجاد شده به صورت ایستا هنوز واکنشپذیر هستند: Next.js برنامه سمت کلاینت شما را هیدراته میکند تا تعاملی کامل به آن بدهد.
علاوه بر این، اگر صفحه به پارامترهای پرس و جو در URL متکی باشد، Next.js پس از هیدراتاسیون برنامه شما را به روز می کند.
Next.js به صورت بصری به شما اطلاع می دهد که آیا صفحه ای به صورت ایستا در طول توسعه ایجاد می شود. این مصنوع بصری را می توان با کلیک بر روی آن پنهان کرد.

صفحات ایجاد شده به صورت ایستا نیز در خروجی ساخت Next.js نشان داده خواهند شد:

در بسیاری از موارد، هنگامی که برنامه های React را می سازید، در نهایت به نوعی پشتیبان نیاز دارید. یا برای بازیابی داده ها از پایگاه داده یا پردازش داده های ارائه شده توسط کاربران شما (به عنوان مثال فرم تماس).
ما متوجه شدیم که بسیاری از کاربرانی که به پشتیبان نیاز دارند API خود را با استفاده از یک سرور سفارشی ساخته اند. در انجام این کار، آنها با مشکلات زیادی مواجه شدند. به عنوان مثال، Next.js کد سرور سفارشی را کامپایل نمی کند، به این معنی که شما نمی توانید از آن استفاده کنید import / export یا TypeScript.
به همین دلیل، بسیاری از کاربران به پیاده سازی خط لوله ساخت سفارشی خود در سرور سفارشی پایان دادند. اگرچه این کار هدف آنها را حل کرد، اما مستعد مشکلات زیادی است: به عنوان مثال، هنگامی که پیکربندی نادرست انجام شود، لرزش درخت برای کل برنامه آنها غیرفعال می شود.
این سؤال را ایجاد کرد: اگر تجربه توسعهدهندهای را که Next.js ارائه میکند برای ساختن یک Backend API منتقل کنیم، چه؟
امروز ما مشتاق معرفی مسیرهای API هستیم، بهترین تجربه توسعه دهنده Next.js در کلاس برای ساختن باطن شما.
برای شروع استفاده از مسیرهای API، یک دایرکتوری به نام ایجاد می کنید api/ داخل از pages/ اشاره گر
هر فایل در این دایرکتوری به طور خودکار به نگاشت می شود /api/، به همان روشی که سایر فایل های صفحه به مسیرها نگاشت می شوند.
برای مثال، pages/api/contact.js نقشه برداری خواهد شد /api/contact.
توجه داشته باشید: مسیرهای API از مسیرهای پویا نیز پشتیبانی می کنند!
تمام فایل های داخل pages/api/ دایرکتوری یک تابع کنترل کننده درخواست را به جای React Component صادر می کند:
export default function handle(req, res) {
res.end('Hello World');
}
به طور معمول، نقاط پایانی API برخی از داده های ورودی، مانند رشته درخواست، بدنه درخواست یا کوکی ها را می پذیرند و با داده های دیگر پاسخ می دهند.
هنگامی که در حال تحقیق در مورد افزودن پشتیبانی از مسیرهای API به Next.js بودیم، متوجه شدیم که در بسیاری از موارد کاربران مستقیماً از اشیاء درخواست و پاسخ Node.js استفاده نمیکنند. در عوض، آنها از یک انتزاع ارائه شده توسط کتابخانه های سرور مانند Express استفاده کردند.
دلیل این امر این است که در بسیاری از موارد داده های ورودی نوعی متن است که ابتدا باید تجزیه شود تا مفید باشد. بنابراین این کتابخانههای سرور خاص به حذف بار تجزیه دستی دادهها، اغلب از طریق میانافزار، کمک میکنند. متداولترین موارد استفادهشده، رشته پرس و جو، متن و تجزیه کوکی را ارائه میکنند، اما هنوز برای شروع به تنظیماتی نیاز دارند.
API Routes در Next.js این میانافزار را بهطور پیشفرض ارائه میکند تا بتوانید فوراً در ساختن نقاط پایانی API سازنده باشید:
export default function handle(req, res) {
console.log(req.body); // The request body
console.log(req.query); // The url querystring
console.log(req.cookies); // The passed cookies
res.end('Hello World');
}
علاوه بر استفاده از داده های ورودی، نقطه پایانی API شما معمولاً داده ها را نیز برمی گرداند. به طور معمول این پاسخ JSON خواهد بود. Next.js فراهم می کند res.json() به طور پیش فرض برای تسهیل ارسال داده ها:
export default function handle(req, res) {
res.json({ title: 'Hello World' });
}
وقتی تغییراتی در نقاط انتهایی API در حال توسعه ایجاد میکنید، کد بهطور خودکار بارگیری میشود، بنابراین نیازی به راهاندازی مجدد سرور نیست.
لینک را به عنوان کپی کنیدواکشی اولیه در Viewport س
Next.js 9 به طور خودکار واکشی اولیه می شود کامپوننت ها همانطور که در viewport ظاهر می شوند.
این ویژگی با سرعت بخشیدن به پیمایش به صفحات جدید، پاسخگویی برنامه شما را بهبود می بخشد.
Next.js از Intersection Observer برای واکشی اولیه دارایی های مورد نیاز در پس زمینه استفاده می کند.
این درخواست ها از اولویت پایینی برخوردارند و مشمول آن هستند fetch() یا درخواست های XHR اگر کاربر ذخیره داده را فعال کرده باشد، Next.js از واکشی اولیه خودکار جلوگیری می کند.
با تنظیم، میتوانید از این ویژگی برای صفحاتی که کمتر بازدید شدهاند انصراف دهید prefetch دارایی به false:
Link href="/terms" prefetch={false}>
a>Terms of Servicea>
Link>
لینک را به عنوان کپی کنیدAMP به طور پیش فرض بهینه شده است
Next.js 9 اکنون AMP بهینه سازی شده را به طور پیش فرض برای صفحات AMP-first و ترکیبی AMP ارائه می کند.
تا زمانی که صفحات AMP فعال هستند، Next.js به طور خودکار خروجی آنها را بهینه می کند. این بهینهسازیها میتوانند تا ۵۰٪ سرعت رندر بالاتری داشته باشند!
این تغییر توسط سباستین بنزکار شگفت انگیز AMP Optimizer.
لینک را به عنوان کپی کنیدحذف کد مرده برای typeof window شاخه ها
Next.js 9 جایگزین می شود typeof window با مقدار مناسب خود (undefined یا object) در طول ساخت سرور و کلاینت. این تغییر به Next.js اجازه می دهد تا به طور خودکار کدهای شکسته را از برنامه تولیدی شما حذف کند.
اگر کاربران فقط کد سرور داشته باشند، باید اندازه بسته های سمت سرویس گیرنده را کاهش دهند getInitialProps یا سایر بخش های کاربرد آنها.
لینک را به عنوان کپی کنیدکامپایل نشانگر
در نسخههای قبل از ۹، تنها راه برای اطلاع از اینکه جایگزینی کد داغ اتفاق میافتد (و زنجیره ابزار کامپایلر Next.js کار میکند) این است که به کنسول توسعهدهنده نگاه کنید.
هر چند بار، به جای آن به رندر حاصل نگاه میکند و تشخیص اینکه Next.js هنوز کار کامپایل را انجام میدهد یا خیر را دشوار میکند. برای مثال، ممکن است تغییراتی در سبکهای صفحه ایجاد کنید که ظریف هستند و بلافاصله متوجه بهروزرسانی آنها نخواهید شد.
به همین دلیل، ما یک RFC / “مشکل اول خوب” ایجاد کردهایم تا راهحلهای بالقوه برای مشکل نشاندهنده کار در حال انجام را مورد بحث قرار دهیم.
ما از بسیاری از طراحان و مهندسان درباره RFC بازخورد دریافت کردیم، مانند آنچه که آنها ترجیح می دهند و دستورالعمل های طراحی اشاره گر بالقوه.
رافائل آلمیدا از این فرصت استفاده کرد و با تیم ما همکاری کرد و یک اندیکاتور کاملاً جدید را پیاده سازی کرد که اکنون به طور پیش فرض در Next.js 9 موجود است.
هر زمان که Next.js یک کار کامپایل انجام می دهد، یک مثلث کوچک در گوشه سمت راست پایین صفحه می بینید!
لینک را به عنوان کپی کنیدخروجی کنسول
به طور سنتی، هنگامی که تغییرات توسعه ایجاد می کنید، Next.js یک نشانگر وضعیت ساخت با نوارهای وضعیت بارگیری بازشو نمایش می دهد و به طور مداوم صفحه را هنگام ایجاد تغییرات پاک می کند.
این رفتار باعث ایجاد برخی مشکلات می شود. اکثراً خروجی کنسول را از کد برنامه شما پاک می کند، مثلاً وقتی اضافه می کنید console.log به اجزای شما اما همچنین هنگام استفاده از ابزارهای خارجی که خروجی گزارش را ادغام می کنند مانند Vercel CLI یا docker-compose.
با شروع با Next.js 9، گزارش خروجی کمتر می پرد و دیگر صفحه را پاک نمی کند. این اجازه می دهد تا تجربه کلی بهتری داشته باشید، زیرا پنجره ترمینال شما اطلاعات مرتبط بیشتری خواهد داشت و کمتر سوسو می زند، در حالی که Next.js با ابزارهایی که ممکن است قبلاً استفاده می کنید بهتر ادغام می شود.
تشکر ویژه از جاستین چیس برای کمک به تمیز کردن خروجی.
ساختن برنامه کاربردی شما برای استفاده در تولید next build اکنون یک نمای دقیق از تمام صفحات ایجاد شده به شما ارائه می دهد.
هر صفحه به طور خودکار آماری را دریافت می کند.
مهمترین چیز اندازه بسته بندی است. همانطور که برنامه شما رشد می کند بسته های جاوا اسکریپت شما نیز رشد می کنند، این نشانگر زمان ساخت به شما کمک می کند رشد بسته های تولیدی خود را نشان دهید. در آینده، همچنین میتوانید برای صفحاتی که در ساخت تولید ناموفق هستند، بودجه عملکردی تعیین کنید.

علاوه بر اندازه های بسته، ما همچنین نشان می دهیم که چه تعداد جزء پروژه و node_modules کامپوننت ها در هر صفحه استفاده می شوند. این نشان دهنده پیچیدگی صفحه است.

هر صفحه همچنین نشانی از بهینه سازی استاتیک یا ارائه شده در سمت سرور دارد، زیرا هر صفحه می تواند رفتار متفاوتی داشته باشد.

اکنون هر صفحه ای می تواند یک شی پیکربندی را صادر کند. در ابتدا، این پیکربندی به شما امکان میدهد تا AMP را انتخاب کنید، اما در آینده میتوانید گزینههای بیشتر مربوط به صفحه را پیکربندی کنید.
export const config = { amp: true };
export default function AboutPage(props) {
return h3>My AMP About Page!h3>;
}
برای انتخاب رندر هیبریدی AMP، می توانید از مقدار استفاده کنید 'hybrid':
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 یک جزء مرتبه بالاتر به نفع این پیکربندی جدید حذف شد.
ما یک کد مد ارائه کرده ایم که به طور خودکار استفاده از آن را تبدیل می کند withAmp به شی پیکربندی جدید. می توانید در راهنمای ارتقا اطلاعات بیشتری در این مورد بخوانید.
ما اخیراً تغییراتی در ابزارهای خود ایجاد کردهایم تا تجربه بهتری را ارائه دهیم و در عین حال به پایگاه کد کمک کرده و با رشد پایگاه کد از ثبات اطمینان حاصل کنیم.
همانطور که در قسمت TypeScript خواندید، هسته Next.js قبلاً در TypeScript نوشته شده است و انواع به طور خودکار برای برنامه های Next.js برای استفاده تولید می شوند. علاوه بر اینکه برای برنامههایی که با استفاده از Next.js ساخته میشوند مفید است، هنگام کار بر روی پایگاه کد زیرین نیز مفید است. زیرا به طور خودکار اشتباهات تایپی و تکمیل خودکار دریافت می کنید.
Next.js قبلاً مجموعه نسبتاً بزرگی از آزمایشهای یکپارچهسازی داشت که شامل بیش از 50 برنامه Next.js بود که آزمایشهایی علیه آنها اجرا میشد. این تستها تضمین میکنند که وقتی نسخه جدید منتشر میشود، بهروزرسانی بدون مشکل انجام میشود، زیرا ویژگیهایی که قبلاً در دسترس بودند در برابر همان مجموعه آزمایشی آزمایش میشوند.
اکثر تستهای ما تستهای یکپارچهسازی هستند، زیرا در بسیاری از موارد توسعهدهندگان واقعی را با استفاده از Next.js در توسعه کپی میکنند. به عنوان مثال، ما تست هایی داریم که تغییرات را در یک برنامه Next.js تقلید می کنند تا ببینیم آیا جایگزینی ماژول داغ کار می کند یا خیر.
تستهای یکپارچهسازی ما بیشتر بر اساس سلنیوم وبدرایور است که برای آزمایش در کروم بدون هد با chromedriver ترکیب کردیم. با این حال، مشکلات خاصی در مرورگرهای دیگر، به ویژه مرورگرهای قدیمی مانند اینترنت اکسپلورر 11، به مرور زمان رخ خواهد داد.
از آنجایی که ما از سلنیوم استفاده می کردیم، توانستیم تست های خود را به صورت خودکار در چندین مرورگر اجرا کنیم.
ما در حال حاضر مجموعه آزمایشی خود را در کروم، فایرفاکس، سافاری و اینترنت اکسپلورر 11 اجرا می کنیم.
تیم Google Chrome در حال کار بر روی بهبود Next.js با مشارکت در RFCها و درخواستهای کششی است.
هدف از این همکاری بهبود عملکرد در مقیاس بزرگ با تمرکز بر اندازه بسته، زمان شارژ و هیدراتاسیون است.
برای مثال، این تغییرات تجربه وبسایتهای کوچک و همچنین تجربه اپلیکیشنهای عظیمی مانند Hulu، Twitch و Deliveroo را بهبود میبخشد.
لینک را به عنوان کپی کنیدماژول / Nomodule
اولین حوزه تمرکز، ارائه جاوا اسکریپت مدرن به مرورگرهایی است که از جاوا اسکریپت مدرن پشتیبانی می کنند.
به عنوان مثال، Next.js در حال حاضر نیاز به ارائه چند فایل برای async/await سینتکس مانند کد می تواند در مرورگرهایی اجرا شود که از آن پشتیبانی نمی کنند async/await که می شکست.

برای جلوگیری از شکستن مرورگرهای قدیمی در حین ارسال جاوا اسکریپت مدرن به مرورگرهایی که از آن پشتیبانی می کنند، Next.js از الگوی ماژول/نومول استفاده می کند. الگوی ماژول/نومول مکانیزم قابل اعتمادی را برای ارائه جاوا اسکریپت مدرن به مرورگرهای مدرن ارائه میکند، در حالی که به مرورگرهای قدیمی اجازه میدهد با بالشتکهای زیاد به ES5 برگردند.
RFC برای module/nomodule در Next.js را میتوانید در اینجا پیدا کنید.
لینک را به عنوان کپی کنیدتقسیم بسته بهبود یافته
استراتژی فعلی برای تفکیک بستهها در Next.js مبتنی بر یک اکتشافی مبتنی بر نسبت است تا ماژولها را در یک بخش «مشترک» قرار دهد. از آنجایی که جزئیات بسیار کمی وجود دارد، زیرا تنها یک بسته وجود دارد، کد یا به صورت غیر ضروری دانلود می شود (زیرا قسمت Commons ممکن است شامل کدهایی باشد که واقعاً برای یک مسیر خاص مورد نیاز نیست)، یا کد در چندین بسته صفحه کپی می شود.

RFC برای تقسیم بسته های پیشرفته را می توانید در اینجا پیدا کنید.
لینک را به عنوان کپی کنیدسایر پیشرفت ها
تیم Chrome همچنین روی بسیاری از بهینهسازیها و تغییرات دیگری کار میکند که Next.js را بهبود میبخشد. RFC برای اینها به زودی به اشتراک گذاشته می شود.
این RFCها و درخواستهای کششی بهعنوان «Contributions» علامتگذاری شدهاند، بنابراین میتوان آنها را به راحتی در ردیاب شماره Next.js پیدا کرد.
ما از دیدن ادامه رشد انجمن Next.js هیجان زده هستیم.
این نسخه دارای بیش از 65 نویسنده درخواست کشش است که در بهبودها یا نمونه های عمده مشارکت دارند.
در مورد مثالها، اکنون بیش از 200 مثال از نحوه ادغام Next.js با کتابخانهها و فناوریهای مختلف ارائه میدهیم! از جمله اکثر css-in-js و کتابخانه های استخراج داده.
- خرج کردیم 720 همکار فرود حداقل 1 نامزدی.
- این پروژه در GitHub ستاره دار است 38600 بار.
- پایان 3400 درخواست دانلود از چاپ اول ارسال شده اند، یعنی بیش از 800 از آخرین نسخه اصلی!
انجمن Next.js از آخرین نسخه اصلی با بیش از دو برابر شده است 8600 عضو. به ما بپیوندید
ما از جامعه خود و همه بازخوردها و نظرات خارجی که به شکل دادن به این نسخه کمک کرد سپاسگزاریم.



