NAME
nextjs-16-cache-components — Next.js 16, ক্যাশে কম্পোনেন্ট এবং রিঅ্যাক্ট কম্পাইলার: আসলে কি পরিবর্তন হয়
SYNOPSIS
cat nextjs-16-cache-components.md
DESCRIPTION
কয়েক বছর ধরে Next.js-এর সবচেয়ে বিরক্তিকর প্রশ্ন হল: "এই পৃষ্ঠাটি কি স্ট্যাটিক নাকি গতিশীল?"। এটি একটি সাধারণ প্রশ্ন বলে মনে হচ্ছে, যতক্ষণ না আপনি cookies(), একটি fetch এ বিভিন্ন বিকল্প, একটি ডাটাবেস ক্লায়েন্ট, একটি CMS, একটি শপিং কার্ট, বা কাস্টম সামগ্রীর একটি অংশ যুক্ত না করেন৷
Next.js 16 আকর্ষণীয় কারণ এটি এই কথোপকথনটিকে কম রহস্যময় করার চেষ্টা করে। এটি জটিলতা দূর করে না, তবে এটি মানসিক মডেলকে পরিবর্তন করে: রুটগুলি ডিফল্টরূপে গতিশীল, যেখানে প্রয়োজন সেখানে ক্যাশে নিজেকে ঘোষণা করে এবং Suspense সতেজ থাকা অংশগুলির সাথে দ্রুত শেল রচনা করার প্রাকৃতিক উপায় হয়ে ওঠে।
বোঝার বৈশিষ্ট্য হল ক্যাশে উপাদান। স্টেবল টার্বোপ্যাক, রিঅ্যাক্ট কম্পাইলার, proxy.ts, এবং নতুন অবৈধকরণ APIগুলি গুরুত্বপূর্ণ, কিন্তু তারা একই সমস্যার চারপাশে ঘোরে: পর্দার আড়ালে ফ্রেমওয়ার্ক কী সিদ্ধান্ত নিয়েছে তা অনুমান না করেই দ্রুত অ্যাপ তৈরি করা।
কারণ এই জিনিসটা গুরুত্বপূর্ণ
একটি বাস্তব অ্যাপে আপনার শুধু "স্ট্যাটিক পেজ" এবং "ডাইনামিক পেজ" নেই। আপনি বিভিন্ন প্রয়োজন সঙ্গে বিভিন্ন টুকরা আছে.
পণ্য শীট দিনে কয়েকবার পরিবর্তন হতে পারে। দাম আরো প্রায়ই পরিবর্তন হতে পারে. প্রাপ্যতা প্রায় লাইভ হতে হবে. ব্যবহারকারীর নাম ব্যক্তিগত। পর্যালোচনা স্ট্রিম করা যেতে পারে. সাইডবার স্থিতিশীল হতে পারে। কার্ট করে না।
আপনি যদি সবকিছুকে একক হিসাবে বিবেচনা করেন তবে আপনি সর্বদা দুটি চরমের মধ্যে একটিতে শেষ হবেন:
- আক্রমণাত্মক ক্যাশিং এবং পুরানো ডেটা দেখার ঝুঁকি;
- সর্বত্র গতিশীল রেন্ডারিং এবং কর্মক্ষমতা প্রয়োজনের চেয়ে খারাপ।
ক্যাশে উপাদান এই মিথ্যা পছন্দ এড়াতে অবিকল পরিবেশন করে।
অনুশীলনে মডেল
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 ব্যবহার করছেন না তখন এটি বিশেষভাবে কার্যকর। অনেক অ্যাপ প্রিজমা, ড্রিজল, অভ্যন্তরীণ SDK, 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;
- ওয়েবপ্যাক প্লাগইন বাকি;
- সমালোচনামূলক পৃষ্ঠা;
- নির্মাণ সময়ের মধ্যে পার্থক্য।
নতুন প্রকল্পের জন্য, আমি ডিফল্ট থেকে শুরু করব। প্রাপ্তবয়স্কদের জন্য, আমি একটি পরিমাপিত স্থানান্তর করব।
প্রতিক্রিয়া কম্পাইলার: শব্দ সরান, চিন্তা নয়
রিঅ্যাক্ট কম্পাইলার 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;
আমি এটি একটি যাদু ধুলো মত আচরণ করা হবে না. কম্পাইলার সাহায্য করে যখন কোডটি প্রতিক্রিয়ার নিয়মগুলি ভালভাবে অনুসরণ করে। যদি উপাদানগুলির অদ্ভুত পার্শ্বপ্রতিক্রিয়া, লুকানো মিউটেশন বা খারাপভাবে ব্যবহৃত হুক থাকে, তবে প্রথমে এটি ঠিক করা দরকার।
এটি চেষ্টা করার স্বাস্থ্যকর উপায়:
- আপডেট
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.tsproxy.tsএ স্থানান্তরিত করি; - আমি বিল্ড এবং সমালোচনামূলক পৃষ্ঠাগুলি পরীক্ষা করি;
- আমি একটি বিভাগে ক্যাশে উপাদানগুলি সক্ষম করি যেখানে ক্যাশে বর্তমানে ঘর্ষণ তৈরি করে;
- আমি ট্যাগ এবং অবৈধকরণের জন্য নিয়মগুলি সংজ্ঞায়িত করি;
- আমি আলাদাভাবে রিঅ্যাক্ট কম্পাইলার চেষ্টা করি;
- আগে এবং পরে মেট্রিক্সের তুলনা।
ভাল মাইগ্রেশন এমন নয় যে সমস্ত নতুন বৈশিষ্ট্য ব্যবহার করে। এটি অ্যাপটির আচরণকে আরও পাঠযোগ্য করে তোলে।
চিন্তাধারায় কি পরিবর্তন আসে
Next.js 16 সম্পর্কে সবচেয়ে দরকারী জিনিস হল এটি আপনাকে উদ্দেশ্যগুলিকে আরও ভাল নাম দিতে বাধ্য করে৷ একটি ফাংশন শুধুমাত্র "ডাটাবেস থেকে পণ্য পান" নয়। এটি "পণ্যটি পান, আমি এটিকে ঘন্টার জন্য ক্যাশে করতে পারি, আমি এই ট্যাগটি দিয়ে এটি বাতিল করি"। একটি উপাদান শুধুমাত্র "পৃষ্ঠা রেন্ডার" নয়। এটি "এটি দ্রুত শেল, এই অংশটি ব্যক্তিগত, এটি স্ট্রিমিং আসে।"
প্রথমে মনে হয় বেশি কাজ। তখন তা প্রশান্তিতে পরিণত হয়। পারফরম্যান্সের সিদ্ধান্তগুলি আর ডিফল্ট, হিউরিস্টিকস এবং উপজাতীয় স্মৃতির সংমিশ্রণে লুকানো থাকে না। তারা কোড আছে.
দরকারী সূত্র
METADATA
- date: 2026-05-24
- reading: 6 min
- author: Filippo Spinella
- tags: Next.js, React, Frontend, Performance