Next.js 16.4 منتشر شد: Cache Components حالا انتخاب پیش‌فرض است
نویسنده: آرش لطیفی
Next.js 16.4 دیروز (۶ اکتبر) ریلیز شد؛ تیم رسمی برای اولین‌بار Cache Components را برای همه اپها توصیه کرد و create-next-app هم دیفالت روشنش کرد. اینجا می‌گم چی عوض شده، چه چیزهای تازه‌ای اضافه شده و برای پروژه‌های موجود چیکار کنی.
TL;DR — Next.js 16.4 (۶ اکتبر ۲۰۲۶) مهم‌ترین ریلیز ۱۶.x است: Cache Components از «آزمایشی، کاری نکن» به «برای هر اپی توصیه می‌شود» ارتقا پیدا کرد،
create-next-appدیفالت روشنش کرد، ابزارnext upgrade --agentبرای مایگریشن با هوش مصنوعی اضافه شد و React به 19.3 رسید.
چرا این ریلیز فرق دارد؟
تیم Next.js در پست رسمی 16.4 نوشته که مدل جدید برنامه‌نویسی — یعنی Cache Components — از شروع 16.x در حال شکل‌گرفتن بود ولی توصیه عمومی نمی‌شد، چون در بعضی حالت‌ها هم‌سطح مدل قبلی از نظر هزینه و کارایی نمی‌رسید. با 16.4 این شکاف‌ها بسته شده و برای اولین‌بار رسماً می‌گویند: Cache Components بهترین انتخاب برای هر اپ Next.js است.
سه ادعای اصلی این مدل طبق پست رسمی:
- لود اولیه سریع، حتی برای صفحات شخصی‌سازی‌شده
- ناوبری کلاینتی آنی (instant navigation) در اپهای سرور-رندر
- کش به‌صورت opt-in، declarative و قابل‌ترکیب
ایده اصلی: 'use cache' مثل Cache-Control در سطح کامپوننت
شبیه‌ترین تشبیهی که خود پست رسمی می‌زند: 'use cache' یعنی نسخه کامپوننتی از هدر Cache-Control در HTTP. یک مثال ساده از پست:
قدرت اصلی ترکیبشه: در یک صفحه می‌توانی آواتار کاربر را request-time رندر کنی و متن پست وبلاگ را از پیش prerender کنی — همه در یک پاسخ HTTP. مدل کش ضمنیِ نسخه‌های قبلی App Router جای خودش را به این انوتیشن‌های صریح می‌دهد.
راهاندازی
فعالسازی با دو فلگ در کانفیگ:
partialPrefetching که قبلاً جدا از Cache Components بود، حالا رسماً بخشی از مدل محسوب می‌شود.
قابلیت تازه: ensureStatic
یکی از دردهای همیشگی این بود که یک کامپوننت داینامیک ناخواسته صفحه‌ای را که باید کاملاً استاتیک باشد، داینامیک می‌کرد. در 16.4 با ensureStatic می‌توانی تضمین کنی shell یا prefetch یا navigation کامل یک روت استاتیک بماند:
با مقدار "navigation" اگر هر کامپوننت داینامیک در مسیر باشد، خود build خطا می‌دهد. برای پروژه‌هایی که هزینه سرور برایشان مهم است، این یعنی دیگر «داینامیک قاچاقی» در صفحات استاتیک نداری.
ابزار مایگریشن با دستیار هوش مصنوعی
برای اپهای موجود، 16.4 ابزار next upgrade --agent را معرفی کرده که به ایجنت‌های کدنویسی راهنمای version-specific برای آپگرید می‌دهد و Skillهای مخصوص برای ریفکتورهای لازم جهت پذیرش Cache Components ارائه شده. یعنی مسیر رسمی مایگریشن دیگر «دسترس گوگل کن و باگ بگیر» نیست.
بهبودهای عمومی برای همه اپها
طبق پست رسمی، اینها مستقل از Cache Components برای همه کار می‌کنند:
- مصرف حافظه و حجم دیسک کمتر در حالت dev
- زمان کامپایل کمتر
- باندل production کوچکتر
- آپگرید به React 19.3
از چنج‌لاگ ریلیز هم چند مورد عملی قابل‌ذکر است: رفع باگ ناوبری Back قبل از hydration، حفظ prefetching per-segment بعد از ناوبری داینامیک، اصلاح تشخیص proxy.ts با pageExtensions ترکیبی، و پشتیبانی Turbopack از مقادیر false در resolveAlias.
چک‌لیست آپدیت
- [ ]
npm install next@16.4یاpnpm add next@16.4در یک برنچ جدا - [ ] تست‌ها و build را اجرا کن؛ مخصوصاً صفحاتی که به کش ضمنی تکیه دارند
- [ ] برای اپ جدید: با
create-next-appبساز — Cache Components دیفالت فعاله - [ ] برای اپ موجود:
next upgrade --agentرا امتحان کن تا مایگریشن guided بگیری - [ ] بعد از تثبیت، فلگ‌های
cacheComponentsوpartialPrefetchingرا روشن کن و کامپوننت‌های سنگین داده را با'use cache'علامت بزن - [ ] اگر روت حساسی داری که باید همیشه استاتیک بماند،
ensureStatic = 'navigation'را اضافه کن
جدول خلاصه
| قابلیت | وضعیت قبل (16.3) | وضعیت در 16.4 | |---|---|---| | Cache Components | قابل استفاده ولی توصیه عمومی نمی‌شد | توصیه رسمی برای هر اپ، دیفالت در create-next-app | | Partial Prefetching | جدا از مدل | بخشی رسمی از Cache Components | | ensureStatic | وجود نداشت | جدید — تضمین استاتیک بودن روت در build | | next upgrade --agent | وجود نداشت | جدید — مایگریشن guided با ایجنت | | React | 19.2 (buildهای canary) | 19.3 |
سوالات پرتکرار
Q: اپ من روی 16.3 کار می‌کند، مجبورم فوری آپدیت کنم؟
نه. Cache Components opt-in است و اپهای موجود بدون فعال کردن فلگ‌ها مثل قبل کار می‌کنند. ولی اگر نقشه راه ۱۷ را دارید — که طبق پست رسمی Cache Components دیفالت می‌شود — بهتر است زودتر شروع کنید.
Q: 'use cache' چه فرقی با cacheControl در fetch دارد؟
قبلی مدلِ fetch-level و ضمنی بود؛ 'use cache' در سطح کامپوننت است، صریح، و با cacheLife قابل تنظیم. ترکیب کش کلاینتی، کش سروری پلاگable و رندر request-time در یک صفحه را ممکن می‌کند که مدل قبلی نداشت.
Q: Turbopack حالا دیفالت است؟
از 16.x بله و در 16.4 هم بهبودهای بیشتری گرفته (مثل پشتیبانی از false در resolveAlias و مدیریت بهتر workerهای plugin). اگر روی نسخه قدیمی‌ای هستید که Turbopack ندارید، خود آپدیت به 16.4 نصف راه مایگریشن کش جدید است.