NAME
nextjs-16-cache-components — Next.js 16، Cache اجزاء اور React Compiler: واقعی کیا بدلتا ہے۔
SYNOPSIS
cat nextjs-16-cache-components.md
DESCRIPTION
برسوں سے Next.js میں سب سے زیادہ پریشان کن سوالات میں سے ایک یہ رہا ہے: "کیا یہ صفحہ جامد ہے یا متحرک؟"۔ یہ ایک سادہ سا سوال لگتا ہے، جب تک کہ آپ مختلف اختیارات کے ساتھ cookies()، ایک fetch پر کال شامل نہیں کرتے، ڈیٹا بیس کلائنٹ، CMS، شاپنگ کارٹ، یا حسب ضرورت مواد کا ایک ٹکڑا۔
Next.js 16 دلچسپ ہے کیونکہ یہ اس گفتگو کو کم پراسرار بنانے کی کوشش کرتا ہے۔ یہ پیچیدگی کو ختم نہیں کرتا ہے، لیکن یہ ذہنی ماڈل کو بدل دیتا ہے: راستے پہلے سے طے شدہ طور پر متحرک ہوتے ہیں، جہاں ضرورت ہو وہاں کیشے خود کو ظاہر کرتا ہے، اور Suspense تازہ رہنے والے حصوں کے ساتھ تیز گولے بنانے کا قدرتی طریقہ بن جاتا ہے۔
سمجھنے کے لیے خصوصیت Cache Components ہے۔ Stable Turbopack, React Compiler, proxy.ts، اور نئے invalidation APIs اہم ہیں، لیکن وہ اسی مسئلے کے گرد گھومتے ہیں: پردے کے پیچھے فریم ورک نے کیا فیصلہ کیا اس کا اندازہ لگائے بغیر تیز ایپس بنانا۔
کیونکہ یہ چیز اہمیت رکھتی ہے۔
ایک حقیقی ایپ میں آپ کے پاس صرف "جامد صفحات" اور "متحرک صفحات" نہیں ہوتے ہیں۔ آپ کے پاس مختلف ضروریات کے ساتھ مختلف ٹکڑے ہیں۔
پروڈکٹ شیٹ دن میں چند بار تبدیل ہو سکتی ہے۔ قیمت زیادہ کثرت سے بدل سکتی ہے۔ دستیابی تقریباً لائیو ہونی چاہیے۔ صارف نام ذاتی ہے۔ جائزوں کو نشر کیا جا سکتا ہے۔ سائڈبار مستحکم ہوسکتی ہے۔ ٹوکری نہیں کرتا۔
اگر آپ ہر چیز کو ایک اکائی کے طور پر دیکھتے ہیں، تو آپ ہمیشہ دو انتہاؤں میں سے ایک میں ختم ہوتے ہیں:
- جارحانہ کیشنگ اور پرانے ڈیٹا کو دیکھنے کا خطرہ؛
- ہر جگہ متحرک رینڈرنگ اور کارکردگی ضرورت سے زیادہ خراب۔
اس غلط انتخاب سے بچنے کے لیے Cache Components بالکل ٹھیک کام کرتا ہے۔
عملی طور پر ماڈل
cacheComponents: true کے ساتھ، آپ "use cache" کا استعمال کرتے ہوئے اعلان کر سکتے ہیں کہ کیا کیش ایبل ہے۔ پھر آپ مدت اور ٹیگز کو cacheLife() اور cacheTag() کے ساتھ منسلک کر سکتے ہیں۔ متحرک حصے متحرک رہتے ہیں اور Suspense کے ساتھ الگ تھلگ ہوسکتے ہیں۔
سیٹ اپ چھوٹا ہے:
// next.config.ts import type { NextConfig } from 'next'; const nextConfig: NextConfig = { cacheComponents: true, }; export default nextConfig;
بڑی تبدیلی ترتیب میں نہیں ہے۔ یہ اس میں ہے کہ آپ اجزاء کو کیسے لکھنا شروع کرتے ہیں۔
// app/products/[slug]/page.tsx import { Suspense } from 'react'; import { cacheLife, cacheTag } from 'next/cache'; async function getProduct(slug: string) { 'use cache'; cacheLife('hours'); cacheTag(`product:${slug}`); return db.product.findUnique({ where: { slug } }); } async function ProductDetails({ slug }: { slug: string }) { const product = await getProduct(slug); return ( <section> <h1>{product.name}</h1> <p>{product.description}</p> </section> ); } async function LiveInventory({ slug }: { slug: string }) { const inventory = await db.inventory.findFirst({ where: { slug } }); return <p>{inventory.quantity} pezzi disponibili</p>; } export default async function ProductPage({ params }: { params: Promise<{ slug: string }> }) { const { slug } = await params; return ( <> <ProductDetails slug={slug} /> <Suspense fallback={<p>Controllo disponibilità...</p>}> <LiveInventory slug={slug} /> </Suspense> </> ); }
ضروری نہیں ہے کہ صفحہ تمام کیشڈ یا تمام متحرک ہو۔ پروڈکٹ شیٹ تیز اور دوبارہ قابل استعمال ہوسکتی ہے۔ انوینٹری تازہ رہ سکتی ہے۔ صارف سست ترین حصے کا انتظار کیے بغیر فوراً کچھ دیکھتا ہے۔
use cache قابل عمل دستاویزات ہے۔
مجھے "use cache" کے بارے میں جو چیز پسند ہے وہ یہ ہے کہ یہ آپ کو کسی ارادے کو واضح کرنے پر مجبور کرتا ہے۔ جب آپ کوئی فنکشن پڑھتے ہیں، تو آپ فوراً سمجھ جاتے ہیں کہ کسی نے فیصلہ کیا ہے: "اس ڈیٹا کو دوبارہ استعمال کیا جا سکتا ہے"۔
یہ خاص طور پر مفید ہے جب آپ fetch استعمال نہیں کر رہے ہوں۔ بہت سی ایپس Prisma، Drizzle، اندرونی SDKs، CMS کلائنٹس یا سروس فنکشنز سے ڈیٹا پڑھتی ہیں۔ ان معاملات میں صرف fetch اختیارات پر مبنی پرانی استدلال کافی نہیں تھا۔
انگوٹھے کا اصول:
- cachea مواد نسبتا مستحکم؛
- دانے دار ٹیگ استعمال کریں؛
- متحرک اجازتوں، سیشنز، کارٹس، اطلاعات اور لین دین کی حالتوں کو چھوڑتا ہے۔
- سست حصوں کو اندر رکھیں
Suspense؛ - "ہم نے کارکردگی کو بہتر بنایا" کہنے سے پہلے پیمائش کریں۔
سب کچھ پھینکے بغیر باطل کر دیں۔
کیشے صرف اس صورت میں مفید ہے جب آپ اسے درست طریقے سے اپ ڈیٹ کر سکیں۔ یہاں cacheTag، revalidateTag اور updateTag اہم ہو جاتے ہیں۔
مثال:
'use server'; import { updateTag } from 'next/cache'; export async function updateProductName(productId: string, name: string) { await db.product.update({ where: { id: productId }, data: { name }, }); updateTag(`product:${productId}`); }
اہم تفصیل ٹیگ ہے۔ product:${productId} ایک درست حد بتاتا ہے۔ products ایک بڑی بالٹی کو بتاتا ہے۔ سب سے پہلے بڑی بالٹی آرام دہ ہے؛ کچھ مہینوں کے بعد یہ وجہ بن جاتی ہے کہ آپ عنوان کو تبدیل کرنے کے لیے آدھی ایپ کو باطل کر دیتے ہیں۔
مستحکم ٹربوپیک: وہ حصہ جو آپ ہر روز سنتے ہیں۔
Next.js 16 ٹربوپیک کو ترقی اور تعمیر کے لیے مرکز میں لاتا ہے۔ یہ سب سے زیادہ شاعرانہ خصوصیت نہیں ہے، لیکن یہ وہی ہے جو آپ کام کرتے وقت محسوس کرتے ہیں: سرور جو پہلے شروع ہوتا ہے، تیز تر تروتازہ ہوتا ہے، ایسا بناتا ہے جو زبردستی کافی وقفے کی طرح محسوس ہونے کو روکتا ہے۔
اس نے کہا، میں اپنی آنکھیں بند کرکے کسٹم پلگ ان سے بھرے کوڈ بیس کو منتقل نہیں کروں گا۔ میں چیک کروں گا:
- مقامی تعمیر؛
- غیر معیاری درآمد؛
- MDX، SVG اور CSS؛
- Webpack پلگ ان رہ گئے؛
- تنقیدی صفحات؛
- تعمیراتی اوقات میں فرق
نئے منصوبوں کے لیے، میں پہلے سے طے شدہ سے شروع کروں گا۔ بالغوں کے لیے، میں ایک پیمائش شدہ ہجرت کروں گا۔
ری ایکٹ کمپائلر: شور کو ہٹا دیں، سوچا نہیں۔
React Compiler 1.0 مستحکم ہے اور Next.js 16 اسے reactCompiler کے ساتھ سپورٹ کرتا ہے۔ وعدہ بہت زیادہ دستی یادداشت کو کم کرنے کا ہے: کم memo، کم useMemo، کم useCallback استعمال کیا جاتا ہے "حفاظت کے لئے"۔
// next.config.ts import type { NextConfig } from 'next'; const nextConfig: NextConfig = { reactCompiler: true, }; export default nextConfig;
میں اسے جادوئی دھول کی طرح نہیں سمجھوں گا۔ کمپائلر اس وقت مدد کرتا ہے جب کوڈ React کے اصولوں پر اچھی طرح عمل کرتا ہے۔ اگر اجزاء کے عجیب ضمنی اثرات، پوشیدہ تغیرات یا بری طرح سے استعمال شدہ ہکس ہیں، تو اسے پہلے ٹھیک کرنے کی ضرورت ہے۔
اسے آزمانے کا صحت مند طریقہ:
- اپ ڈیٹ
eslint-plugin-react-hooks؛ - اصل خلاف ورزیوں کو ٹھیک کرنا؛
- اسے ایک کنٹرول شدہ علاقے پر فعال کریں؛
- تعمیراتی وقت اور رویے کی پیمائش؛
- دستی یادداشت کو صرف اس وقت ہٹا دیں جب اس کی مزید ضرورت نہ ہو۔
مقصد ہر useMemo کو مٹانا نہیں ہے۔ مقصد یہ ہے کہ احتیاطی یادداشت لکھنا بند کر دیا جائے کیونکہ ہم رینڈرنگ سے ڈرتے ہیں۔
proxy.ts اور نیٹ ورک کی حد
پرانا middleware.ts proxy.ts بن جاتا ہے۔ یہ نام کی تبدیلی ہے، لیکن یہ سمجھ میں آتا ہے: وہ فائل درخواست کی حد پر بیٹھتی ہے، یہ روایتی بیک اینڈ طرز کا عام مڈل ویئر نہیں ہے۔
// proxy.ts import { NextRequest, NextResponse } from 'next/server'; export default function proxy(request: NextRequest) { const isLoggedIn = Boolean(request.cookies.get('session')); if (!isLoggedIn && request.nextUrl.pathname.startsWith('/dashboard')) { return NextResponse.redirect(new URL('/login', request.url)); } return NextResponse.next(); }
یہاں اصول آسان ہے: اسے چھوٹا رکھیں۔ ری ڈائریکٹ، اوتھ روٹنگ، ہیڈر، ضروری دوبارہ لکھنا۔ اگر یہ دوسرے پسدید کی طرح محسوس ہونے لگتا ہے، تو یہ شاید بہت زیادہ کر رہا ہے۔
میں واقعی ہجرت کیسے کروں گا۔
میں ایک ساتھ تمام خصوصیات کو آن نہیں کروں گا۔ میں یہ کروں گا:
- میں نیکسٹ، ری ایکٹ اور ری ایکٹ DOM کو اپ ڈیٹ کرتا ہوں۔
- میں آفیشل کوڈ موڈ لانچ کرتا ہوں۔
- میں
params،searchParams،cookies()،headers()اورdraftMode()پر بریکنگ تبدیلیوں کو ٹھیک کرتا ہوں؛ - میں
middleware.tsکوproxy.tsمیں منتقل کرتا ہوں؛ - میں تعمیرات اور تنقیدی صفحات کو چیک کرتا ہوں۔
- میں ایک ایسے حصے پر کیشے کے اجزاء کو فعال کرتا ہوں جہاں کیش فی الحال رگڑ پیدا کرتا ہے۔
- میں ٹیگز اور باطل ہونے کے لیے کنونشنز کی وضاحت کرتا ہوں؛
- میں الگ سے React Compiler آزماتا ہوں۔
- پہلے اور بعد کے میٹرکس کا موازنہ۔
اچھی ہجرت وہ نہیں ہے جو تمام نئی خصوصیات کو استعمال کرے۔ یہی چیز ایپ کے رویے کو مزید پڑھنے کے قابل بناتی ہے۔
سوچ کے انداز میں کیا تبدیلی آتی ہے۔
Next.js 16 کے بارے میں سب سے مفید چیز یہ ہے کہ یہ آپ کو ارادوں کو بہتر نام دینے پر مجبور کرتا ہے۔ ایک فنکشن صرف "ڈیٹا بیس سے پروڈکٹ حاصل کرنا" نہیں ہے۔ یہ ہے "پروڈکٹ حاصل کریں، میں اسے گھنٹوں کے لیے کیش کر سکتا ہوں، میں اسے اس ٹیگ سے باطل کرتا ہوں"۔ ایک جزو صرف "صفحہ رینڈر" نہیں ہوتا ہے۔ یہ "یہ تیز ترین شیل ہے، یہ ٹکڑا ذاتی ہے، یہ سٹریمنگ آتا ہے۔"
پہلے تو یہ زیادہ کام لگتا ہے۔ پھر یہ سکون کی شکل اختیار کر لیتا ہے۔ کارکردگی کے فیصلے اب ڈیفالٹس، ہیورسٹکس اور قبائلی یادداشت کے امتزاج میں پوشیدہ نہیں ہیں۔ وہ کوڈ میں ہیں۔
مفید ذرائع
METADATA
- date: 2026-05-24
- reading: 8 min
- author: Filippo Spinella
- tags: Next.js, React, Frontend, Performance