De ani de zile, una dintre cele mai enervante întrebări din Next.js a fost: „Este această pagină statică sau dinamică?”. Pare o întrebare simplă, până când adăugați un apel la cookies(), un fetch cu diferite opțiuni, un client de bază de date, un CMS, un coș de cumpărături sau o bucată de conținut personalizat.

Next.js 16 este interesant, deoarece încearcă să facă această conversație mai puțin misterioasă. Nu elimină complexitatea, dar schimbă modelul mental: rutele sunt dinamice implicit, cache-ul se declară acolo unde este nevoie, iar Suspense devine modalitatea naturală de a compune shell-uri rapide cu părți care rămân proaspete.

Caracteristica de înțeles este Componentele cache. Stable Turbopack, React Compiler, proxy.ts și noile API-uri de invalidare sunt importante, dar se învârte în jurul aceleiași probleme: construirea de aplicații rapide fără a fi nevoie să ghicească ce a decis cadrul în culise.

Pentru că chestia asta contează

Într-o aplicație reală nu aveți doar „pagini statice” și „pagini dinamice”. Aveți piese diferite cu nevoi diferite.

Fișa produsului se poate schimba de câteva ori pe zi. Prețul se poate schimba mai des. Disponibilitatea trebuie să fie aproape live. Numele de utilizator este personal. Recenziile pot fi transmise în flux. Bara laterală poate fi stabilă. Căruciorul nu.

Dacă tratezi totul ca o singură unitate, ajungi întotdeauna în una dintre cele două extreme:

• stocarea în cache agresivă și riscul de a vedea date vechi;
• randare dinamică peste tot și performanță mai slabă decât este necesar.

Cache Components servește tocmai pentru a evita această alegere falsă.

Modelul în practică

Cu cacheComponents: true, puteți declara ceea ce poate fi stocat în cache folosind "use cache". Apoi puteți asocia durata și etichetele cu cacheLife() și cacheTag(). Părțile dinamice rămân dinamice și pot fi izolate cu Suspense.

Configurația este mică:

// next.config.ts
import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  cacheComponents: true,
};

export default nextConfig;

Marea schimbare nu este în configurație. Este în modul în care începi să scrii componentele.

// 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>
    </>
  );
}

Pagina nu trebuie să fie în totalitate în cache sau dinamică. Fișa produsului poate fi rapidă și reutilizabilă. Inventarul poate rămâne proaspăt. Utilizatorul vede ceva imediat, fără să aștepte partea cea mai lentă.

use cache este o documentație executabilă

Lucrul care îmi place la "use cache" este că te obligă să explici o intenție. Când citești o funcție, înțelegi imediat că cineva a decis: „aceste date pot fi refolosite”.

Este util mai ales când nu utilizați fetch. Multe aplicații citesc date de la Prisma, Drizzle, SDK-uri interne, clienți CMS sau funcții de serviciu. În acele cazuri, vechiul raționament bazat doar pe opțiunile fetch nu a fost suficient.

O regulă generală:

• conținutul cacheei relativ stabil;
• utilizați etichete granulare;
• lasă permisiuni dinamice, sesiuni, cărucioare, notificări și stări tranzacționale;
• pune piese lente în interiorul Suspense;
• măsurați înainte de a spune „am îmbunătățit performanța”.

Invalidați fără a arunca totul

Cache-ul este util doar dacă îl puteți actualiza cu precizie. Aici cacheTag, revalidateTag și updateTag devin importante.

Exemplu:

'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}`);
}

Detaliul important este eticheta. product:${productId} indică o limită precisă. products spune unei găleți uriașe. La început găleata uriașă este confortabilă; după câteva luni devine motivul pentru care invalidezi o jumătate de aplicație pentru a schimba un titlu.

Turbopack stabil: partea pe care o auzi în fiecare zi

Next.js 16 aduce Turbopack în centrul dezvoltării și construirii. Nu este cea mai poetică caracteristică, dar este cea pe care o simți în timp ce lucrezi: server care pornește mai devreme, reîmprospătare mai rapidă, build-uri care nu se mai simt ca o pauză de cafea forțată.

Acestea fiind spuse, nu aș migra o bază de cod plină de pluginuri personalizate cu ochii închiși. as verifica:

• construcție locală;
• module non-standard;
• MDX, SVG și CSS;
• Pluginuri Webpack rămase;
• pagini critice;
• diferențe de timp de construcție.

Pentru proiecte noi, aș începe de la implicit. Pentru cei maturi aș face o migrație măsurată.

React Compiler: eliminați zgomotul, nu gândirea

React Compiler 1.0 este stabil și Next.js 16 îl acceptă cu reactCompiler. Promisiunea este reducerea multă memorare manuală: mai puțin memo, mai puțin useMemo, mai puțin useCallback folosit „pentru siguranță”.

// next.config.ts
import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  reactCompiler: true,
};

export default nextConfig;

Nu l-aș trata ca pe un praf magic. Compilatorul ajută atunci când codul respectă bine regulile React. Dacă componentele au efecte secundare ciudate, mutații ascunse sau cârlige prost folosite, trebuie remediat mai întâi.

Modul sănătos de a-l încerca:

1. actualizare eslint-plugin-react-hooks;
2. remediați încălcările reale;
3. activați-l pe o zonă controlată;
4. măsurați timpul de construcție și comportamentul;
5. eliminați memorarea manuală numai atunci când nu mai este necesară.

Scopul este să nu ștergeți fiecare useMemo. Scopul este să nu mai scriem memorări preventive pentru că ne este frică de redare.

proxy.ts și limita rețelei

Vechiul middleware.ts devine proxy.ts. Este o schimbare de nume, dar are sens: acel fișier se află la limita cererii, nu este un middleware generic tradițional în stil backend.

// 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();
}

Regula aici este simplă: păstrați-l mic. Redirecționare, rutare autentificare, anteturi, rescrieri esențiale. Dacă începe să pară un al doilea backend, probabil că face prea mult.

Cum aș migra cu adevărat

Nu aș activa toate funcțiile deodată. as face asta:

1. Actualizez Next, React și React DOM;
2. Lansez codul oficial;
3. Repar modificările de ruptură pe params, searchParams, cookies(), headers() și draftMode();
4. Migrez middleware.ts la proxy.ts;
5. Verific versiunile și paginile critice;
6. Activez Componentele cache într-o secțiune în care memoria cache creează în prezent frecare;
7. Definesc convenții pentru etichete și invalidare;
8. Încerc React Compiler separat;
9. compararea valorilor înainte și după.

Migrarea bună nu este cea care folosește toate funcțiile noi. Este ceea ce face comportamentul aplicației mai lizibil.

Ce se schimbă în modul de gândire

Cel mai util lucru despre Next.js 16 este că te obligă să numești mai bine intențiile. O funcție nu este doar „obține produsul din baza de date”. Este „primiți produsul, îl pot păstra în cache ore în șir, îl invalidez cu această etichetă”. O componentă nu este doar „redarea paginii”. Este „aceasta este carcasa rapidă, această piesă este personală, aceasta vine în streaming”.

La început pare mai multă muncă. Apoi devine o formă de calm. Deciziile de performanță nu mai sunt ascunse într-o combinație de valori implicite, euristică și memorie tribală. Sunt în cod.

Surse utile

• Note de lansare Next.js 16
• Componente cache - documente Next.js
• utilizați memoria cache - documente Next.js
• React Compiler v1.0