Passer des paramètres dans une URL est une pratique courante. Cela permet de déclencher des requêtes dans un moteur de recherche ou de trouver des produits dans un catalogue e-commerce.
Next.js propose plusieurs façons de récupérer ces paramètres. L’approche à utiliser dépend de la manière dont vos pages sont rendues.
Les query params ou search params sont les paramètres qui apparaissent après le ? dans une URL. Par exemple : lbke.fr/ressources?query=nextjs.
Dans Next.js, la façon d’accéder aux search params dépend du type de composant React sous-jacent.
useSearchParams"use client"
import { useSearchParams } from 'next/navigation';
function SearchPage() {
const searchParams = useSearchParams();
const query = searchParams.get('query');
return <h1>Résultats de recherche pour : {query}</h1>;
}
L’utilisation de useSearchParams dans un composant client empêchera le rendu statique pour toute la page, car les paramètres de recherche ne sont pas connus au moment de la compilation.
Next.js vous invitera donc gentiment (mais fermement :)) à wrapper le composant avec un <Suspense> pour pouvoir rendre statiquement le reste de la page.
searchParams directement au niveau de la page.// app/search/page.tsx
export defaut function SearchPage({ searchParams }) {
const query = (await searchParams).query;
return <h1>Résultats de recherche pour : {query}</h1>;
}
Cette prop est asynchrone depuis la version 15 de Next.js, auparavant le await n’était pas nécessaire.
Son utilisation va déclencher le rendu dynamique à la requête, car les searchParams ne sont généralement pas connus lors du rendu statique.
Si un server component enfant doit accéder aux searchParams, vous pouvez les passer en props depuis le composant page.
Nous avons introduit par le passé la notion de Server Context pour éviter le “props drilling” lorsque le composant est fortement imbriqué, cependant ce pattern n’est pas recommandé aujourd’hui.
Les équipes de Next.js sont conscientes de cette limite et devraient proposer une alternative courant 2025.
Lorsque vous utilisez le rendu statique (avec generateStaticParams), vous ne pouvez pas vous appuyer sur la prop searchParams, car le HTML est généré au moment de la compilation, avant que toute requête ne soit effectuée.
Les paramètres d’URL ne sont donc généralement pas encore connu, on ne connaît que les paramètres de routes. On connaît par exemple le nom d’un produit ou d’une catégorie mais pas ce que l’utilisateur va taper dans une barre de recherche.
Vous pouvez toujours utiliser un composant client et useSearchParams. C’est la méthode la plus directe.
Mais pour contourner cette limitation lorsqu’un rendu statique est vraiment nécessaire, le plus simple est de passer par un paramètre de route, avec par exemple une page app/search/[query]/page.tsx
On peut configurer la page pour générer quelques requêtes à l’avance de cette façon, par exemple celles qui sont les plus populaires.
Pour des scénarios plus complexes, vous pouvez mobiliser un pattern que nous appelons “Rendu segmenté”. Il s’agit de réécrire l’URL en amont de la requête, pour pouvoir injecter des search params dans un paramètre de route, et contourner les limitations de Next.js. Découvrez ce pattern plus en détail sur notre site formationnextjs.fr.
Les composants client et les pages rendues dynamiquement peuvent accéder directement aux search params, respectivement via un hook, soit via une prop searchParams fournie par Next.
Pour les cas d’utilisation avancés, le “rendu segmenté” offre un moyen de mélanger le rendu statique et l’utilisation de paramètres d’URL dynamiques.
Vous avez apprécié cette ressource ?
Découvrez toutes nos formations Next.js et Astro en présentiel ou en distanciel