تیم توسعه Next.js یک نسخه اولیه از ۱۵ Next.js منتشر کرده است تا این امکان را برای توسعهدهندگان فراهم کند که قبل از انتشار نسخه پایدار، بتوانند ویژگیهای جدید را مورد آزمایش قرار دهند.
تغییراتی که در نسخه ۱۵ Next.js، که نسخه کاندید انتشار میباشد، صورت گرفته است به طور خلاصه عبارتند از:
fetch
، GET
Route Handlerها و client navigationها بهطور پیشفرض در حافظه cachenext/after
: معرفی API جدید برای اجرای کد پس از اتمام stream توسط responsecreate-next-app
: بهروزرسانی طراحی و افزودن یک flag جدید به منظور فعال کردن Turbopack در توسعه لوکالنسخه ۱۵ Next.js اکنون از نسخه ۱۹ React، که شامل ویژگیهای جدید برای کلاینت و سرور، مانند actionها، میباشد پشتیبانی میکند. در این نسخه App Router بر روی canary channel ، که مربوط به React بوده و برای فریمورکها میباشد، ساخته شده است و به توسعهدهندگان این امکان را میدهد تا قبل از انتشار نسخه ۱۹ از این APIهای جدید React استفاده کرده و نظرات خود را ارائه نمایند.
باید به این نکته توجه داشته باشیم که ممکن است برخی از کتابخانههای third party هنوز با نسخه ۱۹ React سازگار نباشند.
React Compiler یک کامپایلر آزمایشی جدید است که توسط تیم React در Meta ایجاد شده است. کامپایلر کد ما را در سطح عمیقی از جاوااسکریپت و قوانین React درک میکند، که به آن اجازه میدهد تا بهینهسازیهای خودکار را به کدی که داریم اضافه نماید. کامپایلر میزان ذخیرهسازی دستی که توسعهدهندگان باید از طریق APIهایی مانند useMemo
و useCallback
انجام دهند را کاهش میدهد. همین موضوع باعث میشود تا کدها سادهتر شوند، نگهداری آنها آسانتر شده و کمتر مستعد بروز خطا باشند.
در نسخه ۱۵ Next.js پشتیبانی از React Compiler هم اضافه شده است.
برای استفاده از آن babel-plugin-react-compiler
را نصب میکنیم:
npm install babel-plugin-react-compiler
سپس، گزینه experimental.reactCompiler
را در next.config.js
اضافه مینماییم:
const nextConfig = { experimental: { reactCompiler: true, }, }; module.exports = nextConfig;
به صورت اختیاری، میتوانیم کامپایلر را برای اجرا در حالت “opt-in” به صورت زیر پیکربندی کنیم:
const nextConfig = { experimental: { reactCompiler: { compilationMode: 'annotation', }, }, }; module.exports = nextConfig;
توجه به این نکته لازم است، React Compiler در حال حاضر فقط از طریق یک افزونه Babel در Next.js امکانپذیر میباشد که استفاده از آن میتواند منجر به کندتر شدن زمان build شود.
نسخه ۱۴٫۱ Next.js بهبودهایی را در پیامهای خطا و خطاهای hydration ایجاد کرد. در نسخه ۱۵ Next.js تیم توسعه با افزودن نمای خطای hydration بهبودیافته به تلاش خود در زمینه بهبود بیشتر آنها ادامه میدهد. خطاهای hydration اکنون سورس کد خطا را با پیشنهاداتی در مورد نحوه رسیدگی به این مشکل نشان میدهد.
App Router موجود در Next.js با پیشفرضهای caching منتشر شد. اینها به گونهای طراحی شدهاند که بهطور پیشفرض کارآمدترین گزینه را، با قابلیت انصراف در صورت لزوم، ارائه دهند.
تیم توسعه Next.js براساس بازخوردهایی که از توسعهدهندگان دریافت کرده بودند، caching و نحوه تعامل آنها با پروژههایی مانند Partial Prerendering (PPR) و کتابخانههای third party را با استفاده از fetch
دوباره مورد ارزیابی قرار دادند.
در نسخه Next.js 15، پیشفرض ذخیرهسازی برای درخواستهای fetch
، GET
Route Handlerها و Client Router Cache را عوض میکنیم. یعنی این که آن را از پیشفرض cached به پیشفرض uncached تغییر میدهیم. اما اگر قصد داریم رفتار قبلی را حفظ نماییم، میتوانیم با انتخاب caching به کار خود ادامه دهیم.
طبق گفته تیم توسعه Next.js، آنها به کار خود در رابطه با بهبود حافظه caching ادامه خواهند داد و در ماههای آینده جزئیات بیشتری را در اطلاعیه Next.js 15 GA به اشتراک خواهند گذاشت.
Next.js از گزینه Web fetch API cache برای پیکربندی نحوه تعامل درخواست fetch
سمت سرور با حافظه cache HTTP پایدار فریمورک استفاده میکند:
fetch('https://...', { cache: 'force-cache' | 'no-store' });
no-store
– در هر درخواست، منبعی را از یک سرور ریموت دریافت کرده و کش را بهروزرسانی نمیکنیم.force-cache
– در هر درخواست، منبعی را از کش (در صورت وجود) یا یک سرور ریموت دریافت کرده و کش را بهروزرسانی میکنیم.در نسخه Next.js 14، در صورتی که گزینه cache
ارائه نشده باشد، بهطور پیشفرض از force-cache
استفاده میشود، مگر اینکه از یک تابع داینامیک یا گزینه پیکربندی داینامیک استفاده شده باشد.
در نسخه Next.js 15، اگر گزینه cache
ارائه نشده باشد، بهطور پیشفرض از no-store
استفاده میشود. این بدان معناست که درخواستهای fetch
بهطور پیشفرض در حافظه cache ذخیره نمیگردد.
همچنین میتوانیم درخواستهای fetch
caching را از طریق موارد زیر انتخاب کنیم:
cache
بر روی force-cache
در یک فراخوانی fetch
واحدdynamic
روی 'force-static'
برای یک route واحدfetchCache
بر روی 'default-cache'
برای لغو همه درخواستهای fetch
در یک Layout یا Page برای استفاده از force-cache
، مگر اینکه آنها به صراحت گزینه cache
خود را مشخص کنند.در نسخه ۱۴، Route Handlerهایی که از متد GET
HTTP استفاده میکردند بهطور پیشفرض در حافظه cache ذخیره میشدند، مگر اینکه از یک تابع داینامیک یا گزینه پیکربندی داینامیک استفاده کنند. در نسخه Next.js 15، توابع GET
به صورت پیشفرض در حافظه cache ذخیره نمیشوند.
ما همچنین میتوانیم با استفاده از یک گزینه پیکربندی route استاتیک مانند export dynamic = 'force-static'
، کش کردن را انتخاب نماییم.
Route Handlerهای ویژه مانند sitemap.ts
، opengraph-image.tsx
، icon.tsx
و سایر فایلهای متادیتا بهطور پیشفرض ثابت میمانند، مگر اینکه از توابع داینامیک یا گزینههای پیکربندی داینامیک استفاده کنند.
در نسخه Next.js 14.2.0، تیم توسعه یک flag آزمایشی staleTimes
را معرفی کرد تا امکان پیکربندی سفارشی Router Cache را فراهم کند.
در نسخه Next.js 15، این flag همچنان قابل دسترسی است، اما تیم توسعه در حال تغییر رفتار پیشفرض هست تا staleTime
از ۰
برای سگمنتهای Page داشته باشد. این بدان معناست که در حین navigate کردن در برنامه خود، کلاینت همیشه آخرین دادهها را از کامپوننت(های) Page که به عنوان بخشی از navigation فعال میشوند، منعکس میکند. با این حال، هنوز رفتارهای مهمی وجود دارد که بدون تغییر باقی میمانند:
staleTimes.static
) در حافظه cache باقی میماند.با تنظیم پیکربندی زیر میتوانیم رفتار کش Client Router Cache را انتخاب کنیم:
const nextConfig = { experimental: { staleTimes: { dynamic: 30, }, }, }; module.exports = nextConfig;
در نسخه ۱۴ Next.js، تیم توسعه Partial Prerendering(PPR) را که رندر استاتیک و داینامیک را در یک صفحه باهم ترکیب میکند، معرفی کرد.
Next.js در حال حاضر به صورت پیشفرض رندر استاتیک را ارائه میکند، مگر اینکه از توابع داینامیک مانند cookies()
، headers()
و درخواستهای داده ذخیره نشده استفاده کنیم. این APIها یک مسیر کامل را برای رندر داینامیک انتخاب میکنند. ما میتوانیم با استفاده از PPR، هر رابط کاربری داینامیک را در یک حالت Suspense قرار دهیم. هنگامی که یک درخواست جدید مطرح میشود، Next.js بلافاصله یک پوسته HTML استاتیک ارائه میکند، سپس بخشهای داینامیک را در همان درخواست HTTP رندر و استریم مینماید.
تیم توسعه برای اجازه دادن به پذیرش افزایشی، یک گزینه پیکربندی route experimental_ppr
را برای انتخاب Layouts و Pages ویژه در PPR اضافه کرده است:
import { Suspense } from "react" import { StaticComponent, DynamicComponent } from "@/app/ui" export const experimental_ppr = true export default function Page() { return { <> <StaticComponent /> <Suspense fallback={...}> <DynamicComponent /> </Suspense> </> }; }
برای استفاده از گزینه جدید، باید پیکربندی experimental.ppr
را در فایل next.config.js
خود روی 'incremental'
تنظیم نماییم:
const nextConfig = { experimental: { ppr: 'incremental', }, }; module.exports = nextConfig;
هنگامی که همه بخشها PPR را فعال کردیم، بهتر است که مقدار ppr را روی true تنظیم کنیم و آن را برای کل برنامه و همه مسیرهای آینده فعال نماییم.
هنگام پردازش درخواست کاربر، سرور معمولاً وظایفی را انجام میدهد که مستقیماً با محاسبه response مرتبط است. با این حال، ممکن است نیاز به انجام کارهایی مانند ورود به سیستم، تجزیه و تحلیل و سایر همگامسازیهای سیستم خارجی داشته باشیم.
از آنجایی که این کارها مستقیماً به response مربوط نمیشوند، کاربر نباید منتظر تکمیل آنها باشد. به تعویق انداختن کار پس از پاسخ دادن به کاربر باعث ایجاد یک چالش میشود، زیرا توابع بدون سرور، محاسبات را بلافاصله پس از بسته شدن response متوقف میکنند.
after()
یک API آزمایشی جدید است که این مشکل را حل میکند و به ما این امکان را میدهد تا پس از اتمام جریان response، کار را برای پردازش ادامه دهیم و تسکهای ثانویه را قادر میسازد تا بدون این که response اولیه را مسدود کنند، اجرا شده و به کار خود ادامه دهند.
برای استفاده از آن، experimental.after
را به next.config.js
اضافه میکنیم:
const nextConfig = { experimental: { after: true, }, }; module.exports = nextConfig;
سپس، تابع را در سرور کامپوننتها، سرور اکشنها، Route Handlerها یا Middleware وارد میکنیم.
import { unstable_after as after } from 'next/server'; import { log } from '@/app/utils'; export default function Layout({ children }) { // Secondary task after(() => { log(); }); // Primary task return <>{children}</>; }
در نسخه ۱۵ Next.js، برنامه create-next-app
با طراحی جدید بهروزرسانی شده است.
هنگام اجرای برنامه create-next-app
، یک درخواست جدید وجود دارد که از ما میپرسد آیا میخواهیم Turbopack را برای توسعه لوکال فعال کنیم یا خیر، که بهطور پیشفرض بر روی No
تنظیم شده است.
✔ Would you like to use Turbopack for next dev? … No / Yes
flag --turbo
میتواند برای فعال کردن Turbopack استفاده شود.
npx create-next-app@rc --turbo
همینطور برای آسانتر کردن شروع پروژه جدید، یک flag --empty
جدید به CLI اضافه شده است. با استفاده از این flag، هر گونه فایل و استایل اضافی حذف شده و در نهایت یک صفحه «hello world» ساخته میشود.
npx create-next-app@rc --empty
Bundling پکیجهای اکسترنال میتواند عملکرد شروع برنامه ما را بهبود بخشد. در App Router، پکیجهای اکسترنال بهطور پیشفرض bundle میشوند، که ما میتوانیم با استفاده از گزینه جدید پیکربندی serverExternalPackages
، از ایجاد bundleهای خاصی صرف نظر کنیم.
در Pages Router، پکیجهای اکسترنال بهطور پیشفرض bundle نمیشوند، اما میتوانیم با استفاده از گزینه transpilePackages
موجود، لیستی از پکیجها را برای bundle شدن ارائه دهیم. با استفاده از این گزینه پیکربندی باید هر پکیج را مشخص نماییم.
برای یکسانسازی پیکربندی بین App Router و Pages Router، تیم توسعه یک گزینه جدید به نام bundlePagesRouterDependencies
را معرفی میکند تا با bundling خودکار پیشفرض App Router مطابقت داشته باشد. سپس میتوانیم برای صرف نظر از پکیجهای خاص، در صورت نیاز از serverExternalPackages
استفاده نماییم.
const nextConfig = { // Automatically bundle external packages in the Pages Router: bundlePagesRouterDependencies: true, // Opt specific packages out of bundling for both App and Pages Router: serverExternalPackages: ['package-name'], }; module.exports = nextConfig;
۵۰ درصد تخفیف ویژه پاییز فرانت کست تا پایان هفته
کد تخفیف: atm