Next.js 16 Leçon 4 : Fetching de données et Cache Components

Le nouveau modèle de cache de Next.js 16

Next.js 16 introduit les Cache Components : un nouveau système de cache explicite et opt-in. Dans les versions précédentes, le cache était activé par défaut et souvent source de confusion. Désormais, tout est dynamique par défaut — vous choisissez explicitement ce que vous voulez mettre en cache avec la directive "use cache".

Next.js 14/15 (cache implicite)

// fetch() était caché par défaut
// Vous deviez opt-out du cache
const data = await fetch(url, {
  cache: 'no-store',    // pour ne PAS cacher
  next: { revalidate: 60 }, // ou ISR
});

Next.js 16 (cache explicite)

// Tout est dynamique par défaut
// Vous opt-in le cache explicitement
'use cache';

const data = await fetch(url);
// Cette fonction EST maintenant cachée

Activer les Cache Components

TypeScript next.config.ts

import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  cacheComponents: true, // Active "use cache"
};

export default nextConfig;

« use cache » sur une fonction

Ajoutez "use cache" à une fonction async pour que son résultat soit mis en cache. Next.js génère automatiquement une clé de cache basée sur les arguments.

TypeScript lib/posts.ts

import { cacheLife, cacheTag } from 'next/cache';

export async function getPosts() {
  'use cache';
  cacheLife('hours');    // expire après quelques heures
  cacheTag('posts');     // tag pour invalidation ciblée

  const res = await fetch('https://api.example.com/posts');
  return res.json();
}

export async function getPost(slug: string) {
  'use cache';
  cacheLife('max');                   // cache longue durée
  cacheTag(`post-${slug}`);          // tag spécifique à l'article

  const res = await fetch(`https://api.example.com/posts/${slug}`);
  return res.json();
}

ℹ️

Les profils cacheLife

'seconds' → cache très court. 'minutes' → quelques minutes. 'hours' → quelques heures. 'days' → quelques jours. 'weeks' → une semaine. 'max' → cache le plus long possible, revalidation en arrière-plan (recommandé pour le contenu stable).

« use cache » sur un composant entier

TypeScript app/components/PostList.tsx

import { cacheLife, cacheTag } from 'next/cache';

export async function PostList() {
  'use cache';
  cacheLife('hours');
  cacheTag('posts');

  const posts = await getPosts();

  return (
    <ul className="space-y-4">
      {posts.map((p: { id: number; title: string }) => (
        <li key={p.id} className="p-4 border rounded-xl">{p.title}</li>
      ))}
    </ul>
  );
}

// Dans la page, tout le rendu HTML de PostList est caché

Invalider le cache avec revalidateTag()

Quand vous mettez à jour vos données, invalidez le cache par tag. revalidateTag() dans Next.js 16 prend un second argument : le profil de revalidation.

TypeScript app/actions/posts.ts — Server Action

'use server';

import { revalidateTag, updateTag } from 'next/cache';

// Invalide en arrière-plan (stale-while-revalidate)
// L'utilisateur voit les données cachées pendant la revalidation
export async function publishPost(id: string) {
  await db.posts.publish(id);
  revalidateTag('posts', 'max');  // refresh en arrière-plan
}

// Invalide immédiatement (read-your-writes)
// L'utilisateur voit SES changements instantanément
export async function updatePost(id: string, data: PostData) {
  await db.posts.update(id, data);
  updateTag(`post-${id}`);  // invalidation immédiate
}

💡

revalidateTag vs updateTag

revalidateTag(tag, profil) = revalidation en arrière-plan. L’utilisateur voit encore l’ancienne version le temps du refresh (parfait pour le contenu public). updateTag(tag) = invalidation immédiate. L’utilisateur voit ses propres modifications instantanément (parfait pour les formulaires, le profil utilisateur).

Exercice pratique

Activez cacheComponents: true dans votre next.config.ts
Créez une fonction getUsers() avec "use cache", cacheLife('hours') et cacheTag('users')
Utilisez cette fonction dans un Server Component app/users/page.tsx
Créez une Server Action qui appelle revalidateTag('users', 'max') après une mise à jour fictive
Observez dans les logs Next.js que la page est servie depuis le cache lors d’un second appel