Intégrer le dépôt d’un avis
Objectif : Permettre l’envoi d’un avis validé et actualiser la fiche après son enregistrement.
Un avis peut être accepté par le formulaire sans apparaître ensuite sur la fiche si l’écriture et l’actualisation ne sont pas reliées correctement. Vous allez vérifier le parcours complet : le formulaire transmet l’identifiant de la randonnée et le texte, l’action serveur enregistre l’avis, puis la fiche est revalidée.
La fiche et son formulaire existent déjà : le formulaire appelle ajouterAvis et fournit randonneeId ainsi que texte. Comme vous l’avez vu dans les leçons précédentes, la validation et l’écriture restent côté serveur ; il n’est pas nécessaire d’ajouter un composant client pour soumettre ce formulaire HTML.
Vérifier le parcours dans l’action serveur
Dans app/actions/avis.ts, l’ordre des opérations est essentiel : l’action contrôle les champs reçus, transmet uniquement les valeurs validées au service privé, puis appelle revalidatePath après confirmation de l’écriture. L’exemple ci-dessous conserve un contrat HTTP explicite : le service reçoit une requête POST vers la ressource des avis de la randonnée, avec le texte en JSON.
'use server';
import { revalidatePath } from 'next/cache';
const DIFFICULTES_AUTORISEES = ['facile', 'intermediaire', 'difficile'];
export async function ajouterAvis(formData: FormData) {
const randonneeId = formData.get('randonneeId');
const texteRecu = formData.get('texte');
if (typeof randonneeId !== 'string' || !randonneeId.trim()) {
throw new Error('Identifiant de randonnée invalide.');
}
if (typeof texteRecu !== 'string') {
throw new Error('Le texte de l’avis est invalide.');
}
const texte = texteRecu.trim();
if (!texte) {
throw new Error('Le texte de l’avis est obligatoire.');
}
const apiUrl = process.env.RANDONNEES_API_URL;
if (!apiUrl) {
throw new Error('La configuration du service de randonnées est absente.');
}
const reponse = await fetch(
`${apiUrl}/randonnees/${encodeURIComponent(randonneeId)}/avis`,
{
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ texte }),
cache: 'no-store'
}
);
if (!reponse.ok) {
throw new Error('L’avis n’a pas pu être enregistré.');
}
revalidatePath(`/randonnees/${encodeURIComponent(randonneeId)}`);
}Adaptez le chemin de l’endpoint au contrat de votre service si nécessaire ; il doit recevoir l’identifiant dans la route et le commentaire dans le corps JSON. L’URL de base reste une variable d’environnement serveur, sans préfixe public, et la requête d’écriture n’utilise pas le cache. Le tableau de difficultés n’est pas utilisé par cette action : ne le conservez pas dans le fichier, car il ne fait pas partie de son traitement.
Relier l’écriture à l’affichage actualisé
La page de détail doit continuer à importer l’action depuis app/actions/avis.ts et à placer celle-ci dans l’attribut action du formulaire. Le champ caché transmet l’identifiant de la randonnée courante ; le champ de texte porte le nom attendu par l’action. Vérifiez ces trois éléments ensemble : un nom de champ différent, par exemple commentaire à la place de texte, empêcherait l’action de récupérer la valeur prévue.
Après une réponse de succès du service, revalidatePath invalide la fiche correspondant à l’identifiant envoyé. Lorsqu’elle est de nouveau rendue, la page serveur recharge la randonnée et ses avis ; l’avis nouvellement enregistré peut alors apparaître dans la liste. La revalidation ne remplace pas l’écriture : elle intervient seulement après sa réussite, et ne cible pas le catalogue qui n’a pas été modifié.
Les erreurs de l’action restent des erreurs : elles ne doivent pas être converties en succès silencieux ni en liste d’avis vide. La frontière d’erreur déjà présente pour la fiche prend en charge les erreurs de route ; pour une expérience de retour de formulaire plus détaillée, il faudrait une gestion dédiée, qui n’est pas nécessaire pour valider ici l’enchaînement serveur.
À retenir
- Le formulaire transmet l’identifiant de la randonnée et le texte sous les noms attendus par l’action.
- L’action envoie au service privé uniquement les données validées, sans exposer la configuration au navigateur.
- La revalidation ciblée intervient après la réussite de l’écriture et permet à la fiche de relire ses avis.
- Une erreur d’écriture reste une erreur ; elle ne doit pas être présentée comme un avis publié.
Dans la leçon suivante, vous vérifierez les scénarios fonctionnels du catalogue et du dépôt d’avis de bout en bout.