Formulaires 2 — validation & erreurs

Formulaires 1 — contrôlé ou non t'a appris à collecter ce que l'utilisateur tape. Ce module s'occupe de la moitié la plus difficile : décider si c'est acceptable, le dire au bon moment et d'une manière qu'il perçoit, puis survivre à l'envoi. C'est là que se joue la différence entre un formulaire qui « marche sur la démo » et un formulaire qu'on met en production — précisément ce qu'on regarde dans un test technique frontend.

Trois lieux de validation, trois rôles bien distincts

La validation n'a pas un endroit, elle en a trois, et ces trois endroits ne servent pas à la même chose. Le navigateur d'abord : depuis HTML5, l'attribut required, type="email", min, minlength ou pattern suffit à ce qu'il refuse tout seul la soumission — gratuit, instantané, opérant même avant que ton JavaScript ait fini de charger. Ton JavaScript côté client ensuite, pour les règles que le HTML ne sait pas dire (« la date doit être dans le futur », « la clinique doit offrir le service choisi ») et pour contrôler l'expérience : quel message, où, quand, dans quel ton. Le serveur enfin, seul endroit où le code s'exécute sur une machine que l'utilisateur ne contrôle pas — supprimer un required dans les outils de développement prend deux secondes, poster sur ton API avec curl sans jamais ouvrir ta page en prend dix.

La validation native du navigateur : puissante, gratuite, et souvent désactivée

Ce que le navigateur sait faire tout seul est réellement impressionnant, et on te posera la question. Les attributs de contrainte s'écrivent sur les champs, et il les fait respecter à la soumission.

<form action="/api/appointments" method="post">
  <label for="nom">Nom complet</label>
  <input id="nom" name="fullName" type="text" required minlength="2" />

  <label for="email">Courriel</label>
  <!-- type="email" impose une forme "quelque chose@quelque chose" -->
  <input id="email" name="email" type="email" required />

  <label for="date">Date souhaitée</label>
  <!-- min : le navigateur refuse toute date antérieure (en vrai code,
       on générerait la date du jour au lieu de l'écrire en dur) -->
  <input id="date" name="date" type="date" required min="2026-01-01" />

  <label for="tel">Téléphone</label>
  <!-- pattern : une expression régulière que la valeur doit satisfaire -->
  <input id="tel" name="phone" type="tel" pattern="[0-9]{3}-[0-9]{3}-[0-9]{4}" />

  <button type="submit">Réserver</button>
</form>

Zéro ligne de JavaScript, et pourtant : champs obligatoires respectés, email grossièrement vérifié, dates passées refusées, format de téléphone imposé. Le navigateur bloque la soumission, met le focus sur le premier champ fautif et affiche un message. Et type="date" / type="tel" changent aussi le clavier sur téléphone : la sémantique du champ sert l'ergonomie autant que la validation.

Derrière ces attributs, il y a une véritable API, l'API de contrainte (Constraint Validation API) : une propriété validity qui détaille pourquoi c'est invalide (valueMissing, typeMismatch, patternMismatch, rangeUnderflow…), checkValidity() qui renvoie un booléen, setCustomValidity('mon message') pour imposer ton texte, et le pseudo-sélecteur CSS :invalid pour styler l'état fautif.

Alors pourquoi tant d'équipes désactivent-elles tout ça avec l'attribut noValidate posé sur le <form> ? Quatre raisons, qu'il vaut la peine de savoir citer :

1. Le style est hors de contrôle. La bulle native est dessinée par le navigateur : ni ta police, ni tes couleurs, ni ta position. Sur un produit avec une charte graphique, elle jure.
2. Les messages ne sont pas les tiens. « Veuillez renseigner ce champ » est correct mais générique, et varie d'un navigateur à l'autre — impossible de tenir un ton de marque.
3. Elle ne montre qu'une erreur à la fois. Le navigateur s'arrête au premier champ fautif : dix champs, dix allers-retours. Un résumé « voici les 4 champs à corriger » est plus humain.
4. Elle ne sait pas exprimer les règles croisées. « Le mot de passe et sa confirmation doivent correspondre », « si le service est un suivi post-opératoire, la date de chirurgie devient obligatoire » : aucun attribut HTML ne dit ça. Dès qu'un champ dépend d'un autre, on repasse en JS.

<form onSubmit={handleSubmit}>
  <input name="fullName" type="text" required minlength="2" />
  <input name="email" type="email" required />
  <button type="submit">Réserver</button>
</form>

Écrire la validation en JS : une fonction PURE, valeurs → erreurs

Voici le cœur du module, et le patron que tu dois pouvoir écrire de mémoire. L'idée est d'une simplicité désarmante : une fonction qui prend l'objet des valeurs et renvoie un objet des erreurs. Rien d'autre — elle ne touche pas au DOM, n'appelle pas setState, ne connaît même pas l'existence de React. On dit qu'une fonction est pure quand, pour les mêmes entrées, elle rend toujours la même sortie et ne provoque aucun effet de bord. C'est le même mot que dans « le rendu React doit être pur » : même exigence, même bénéfice.

Trois raisons de faire ce choix, toutes défendables en entrevue :

• Testable. Des dizaines de cas vérifiés sans monter un composant, sans clic, sans navigateur : expect(validate({ fullName: '' }).fullName).toBeDefined(), et c'est plié (module Vitest & Testing Library).
• Réutilisable. La même fonction tourne dans le navigateur pour le confort et sur le serveur pour la sécurité — code « isomorphe » : une seule définition des règles, deux lieux d'exécution, zéro divergence possible. En Next.js, où le même fichier TypeScript s'exécute des deux côtés, c'est presque offert.
• Lisible. « Quelles sont les règles de ce formulaire ? » se répond en ouvrant un fichier, au lieu de reconstituer des règles éparpillées dans six gestionnaires d'événements.

function validate(values) {
  const errors = {};
  if (!values.fullName?.trim()) errors.fullName = 'Le nom est requis.';
  if (!/.+@.+\..+/.test(values.email ?? '')) errors.email = 'Courriel invalide.';
  return errors; // {} = valide
}

Deux détails de syntaxe au passage : ?. est l'accès optionnel (values.fullName?.trim() rend undefined au lieu de planter si la clé est absente) et ?? le coalescent nul (values.email ?? '' vaut la chaîne vide si la valeur est nulle). Ensemble, ils rendent le validateur robuste face à un objet incomplet — ce qui arrive dès qu'un champ n'a jamais été touché. Voici la version réelle et typée pour RendezVous : chaque if est une phrase du cahier des charges.

export type AppointmentValues = {
  fullName: string;
  email: string;
  date: string;      // format "AAAA-MM-JJ", celui d'un <input type="date">
  service: string;
};

// Un dictionnaire champ → message. Les clés possibles sont celles des valeurs,
// et Partial dit "chaque clé est facultative" : un champ valide n'a pas d'entrée.
export type AppointmentErrors = Partial<Record<keyof AppointmentValues, string>>;

export function validateAppointment(v: AppointmentValues): AppointmentErrors {
  const errors: AppointmentErrors = {};

  // 1. Nom : présent, et pas juste des espaces (d'où le .trim()).
  if (!v.fullName.trim()) {
    errors.fullName = 'Entre ton nom complet, comme sur ta carte d’assurance maladie.';
  } else if (v.fullName.trim().length < 2) {
    errors.fullName = 'Le nom doit contenir au moins 2 caractères.';
  }

  // 2. Courriel : on reste volontairement PERMISSIF (voir la note plus bas).
  if (!v.email.trim()) {
    errors.email = 'Entre un email : c’est là qu’on envoie ta confirmation.';
  } else if (!/.+@.+\..+/.test(v.email)) {
    errors.email = 'Ce email semble incomplet. Exemple : nom@exemple.ca';
  }

  // 3. Date : présente ET dans le futur. Le "T00:00" force l'heure locale.
  if (!v.date) {
    errors.date = 'Choisis une date de rendez-vous.';
  } else if (new Date(v.date + 'T00:00') < new Date()) {
    errors.date = 'Choisis une date à venir : on ne peut pas réserver dans le passé.';
  }

  // 4. Service : un choix parmi la liste. Vide = rien de sélectionné.
  if (!v.service) {
    errors.service = 'Sélectionne le type de consultation souhaité.';
  }

  return errors; // {} = tout est valide
}

Quarante lignes, et toutes les règles métier du formulaire tiennent dedans. Remarque le else if : un seul message par champ, le plus pertinent — dire à la fois « le nom est requis » et « le nom est trop court » serait bruyant. Pour relire ce que veut dire Partial<Record<…>>, va voir Lire les types TypeScript.

function validate(values) {
  const errors = {};
  if (!values.fullName.trim()) errors.fullName = 'Le nom est requis.';
  if (!values.email.trim()) errors.email = 'Le email est requis.';
  return errors;                 // {} = valide
}

const isValid = validate(values);
if (isValid) send(values);

Quand valider : le moment compte autant que la règle

Tu peux avoir la validation la plus juste du monde et rendre ton formulaire détestable, simplement en la déclenchant au mauvais moment. Trois instants possibles, et le bon choix est une combinaison, pas un des trois.

Au submit : le minimum vital, le comportement par défaut du web. Avantage : l'utilisateur n'est jamais dérangé pendant la saisie. Inconvénient : sur un formulaire long, il découvre quatre problèmes après avoir cru avoir fini, et doit remonter chercher les champs fautifs. Au blur (le champ perd le focus, l'utilisateur passe au suivant) : le meilleur compromis, et de loin. Le signal implicite est clair — « j'ai fini avec ce champ » — et lui dire à ce moment-là « il manque le @ » arrive pile quand il peut encore corriger, sans revenir dix champs en arrière.

À la frappe (onChange, à chaque caractère). Utilisé seul, c'est hostile, et il faut comprendre précisément pourquoi. Le premier caractère du email est un p ; ton validateur constate l'absence de @ et affiche en rouge « Courriel invalide ». L'utilisateur n'a rien fait de mal : il a commencé. Tu viens de le gronder pour avoir obéi. Et ça continue à chaque lettre, jusqu'à ce que la personne se demande si elle sait écrire son propre email. C'est un cas d'école d'anxiété fabriquée par du code.

Pour implémenter ça, il te faut une information supplémentaire par champ : l'utilisateur l'a-t-il déjà quitté au moins une fois ? C'est l'état touched — un second objet, parallèle à values, où l'on note { email: true } dès que le champ perd le focus. Pourquoi un état séparé plutôt que « le champ est vide donc jamais touché » ? Parce qu'un champ peut être vide parce qu'on ne l'a jamais visité, ou parce qu'on l'a visité, rempli, puis effacé. Dans le premier cas, se taire ; dans le second, parler. values dit ce que contient le formulaire, touched dit où l'utilisateur est passé : deux dimensions indépendantes, donc deux états.

const [values, setValues] = useState<AppointmentValues>({ fullName: '', email: '', date: '', service: '' });
// Quels champs l'utilisateur a-t-il déjà quittés ? (touched = "touché")
const [touched, setTouched] = useState<Partial<Record<keyof AppointmentValues, boolean>>>({});
// A-t-on déjà tenté d'envoyer ? Après un submit raté, on montre TOUT.
const [submitAttempted, setSubmitAttempted] = useState(false);

// Les erreurs sont DÉRIVÉES des valeurs : pas de useState pour elles.
const errors = validateAppointment(values);

// On marque le champ comme "touché" quand il perd le focus.
const handleBlur = (e: React.FocusEvent<HTMLInputElement>) => {
  setTouched({ ...touched, [e.target.name]: true });
};

// Un champ n'affiche son erreur que s'il a été quitté, OU si on a déjà tenté d'envoyer.
const visibleError = (field: keyof AppointmentValues) =>
  (touched[field] || submitAttempted) ? errors[field] : undefined;

const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
  const { name, value } = e.target;
  // La formule du module précédent : on remplace UNE clé, on recopie le reste.
  // Rien d'autre à faire : `errors` étant dérivé, il se recalcule au prochain
  // rendu. Un champ déjà `touched` voit donc son message DISPARAÎTRE dès que la
  // saisie devient correcte : c'est le guidage, pas le reproche.
  setValues({ ...values, [name]: value });
};

Le point le plus important de ce bloc n'est pas touched, c'est const errors = validateAppointment(values). Les erreurs ne sont pas un useState : c'est une valeur dérivée, recalculée à chaque rendu. C'est la règle « ne stocke pas ce que tu peux calculer » du module useState & useEffect — deux états à synchroniser finissent toujours par se désynchroniser, et ici il est structurellement impossible que l'erreur affichée corresponde à une ancienne valeur. touched, en revanche, est bien un état : ça, tu ne peux pas le déduire des valeurs.

<input
  name="email"
  value={values.email}
  onChange={(e) => {
    setValues({ ...values, email: e.target.value });
    // Validation immédiate, dès le premier caractère
    setEmailError(
      /.+@.+\..+/.test(e.target.value) ? '' : 'Courriel invalide'
    );
  }}
/>
{emailError && <span style={{ color: 'red' }}>{emailError}</span>}

const [values, setValues] = useState({ fullName: '', email: '', date: '', service: '' });
const errors = validateAppointment(values);

return (
  <>
    <TextField label="Nom complet" value={values.fullName} error={errors.fullName} />
    <TextField label="Courriel"    value={values.email}    error={errors.email} />
    <TextField label="Date"        value={values.date}     error={errors.date} />
  </>
);

Afficher les erreurs de façon ACCESSIBLE

Une erreur qu'on n'a pas perçue n'existe pas — et il y a beaucoup plus de manières de ne pas la percevoir qu'on ne le croit : au lecteur d'écran, en étant daltonien (environ 8 % des hommes), sur un téléphone en plein soleil, ou parce que le message est apparu en haut alors qu'on regardait le bas du formulaire. Un bon message d'erreur est perceptible par plusieurs canaux à la fois. Le patron standard tient en un trio d'attributs, déjà croisés dans HTML sémantique & accessibilité et qui trouvent ici leur usage le plus important :

• aria-invalid="true" sur le champ : dit à la technologie d'assistance que ce champ est en faute. Le lecteur d'écran annonce « non valide » avec le nom du champ — l'équivalent programmatique de la bordure rouge.
• aria-describedby="id-du-message" sur le champ : rattache le message au champ. Sans ça, le message existe visuellement à côté, mais rien dans le code ne dit qu'ils sont liés ; avec ça, le lecteur d'écran lit le libellé puis le message, dans la foulée.
• role="alert" sur l'élément du message : une région live — « si le contenu change, annonce-le immédiatement, même si le focus est ailleurs ». C'est ce qui fait qu'une erreur apparue après le clic sur « Réserver » est entendue, pas seulement affichée.

type Props = {
  id: string;
  label: string;
  error?: string;            // undefined = pas d'erreur sur ce champ
  // ...le reste des props d'un <input>
};

export function TextField({ id, label, error, ...inputProps }: Props) {
  const errorId = `${id}-error`;   // un id stable, dérivé de celui du champ

  return (
    <div className="field">
      {/* htmlFor ↔ id : le clic sur le label donne le focus au champ */}
      <label htmlFor={id}>{label}</label>

      <input
        id={id}
        {...inputProps}
        /* Signale l'état fautif AUX OUTILS, pas seulement à l'œil */
        aria-invalid={error ? true : undefined}
        /* Rattache le message au champ. undefined quand il n'y a pas de message :
           on ne pointe jamais vers un id qui n'existe pas dans le DOM. */
        aria-describedby={error ? errorId : undefined}
      />

      {/* role="alert" : annoncé dès son apparition, même sans focus dessus.
          Le ⚠ et le texte portent l'information : la couleur n'est qu'un renfort. */}
      {error && (
        <p id={errorId} role="alert" className="field__error">
          <span aria-hidden="true">⚠</span> {error}
        </p>
      )}
    </div>
  );
}

Un seul composant réutilisé pour tous les champs : c'est comme ça qu'on garantit que l'accessibilité est appliquée partout, sans dépendre de la discipline de celui qui écrit le formulaire. Note le aria-hidden="true" sur le pictogramme : le lecteur d'écran ne dira pas « signe d'avertissement », il dira le message. L'icône est pour l'œil, role="alert" pour l'oreille.

Trois règles de placement complètent le trio, et elles comptent autant que lui. Le message va SOUS le champ, jamais au-dessus : au-dessus, il pousse le champ vers le bas en apparaissant, tout saute, et sur mobile le doigt vise soudain autre chose. Sous le champ, la mise en page bouge moins et l'ordre de lecture (libellé → champ → message) suit l'ordre logique.

Ne code jamais l'erreur par la seule couleur. Si le rouge est le seul indice, un utilisateur daltonien voit un champ légèrement plus foncé et ne comprend rien. Il faut un texte explicite, et idéalement un second signal non-coloré : pictogramme, bordure plus épaisse. Le principe a un nom en accessibilité — « ne pas véhiculer l'information par une seule caractéristique sensorielle ».

Sur les gros formulaires, ajoute un résumé en tête. Six messages dispersés sur trois écrans de défilement, c'est cruel. Un bloc « 3 champs à corriger : Nom, Courriel, Date » avec des liens qui donnent le focus au champ concerné transforme une chasse au trésor en liste de courses. On y met role="alert" et on lui donne le focus après un submit raté, pour que la personne au lecteur d'écran soit ramenée là où l'information est.

<label htmlFor="date">Date souhaitée</label>
<input
  id="date"
  type="date"
  value={values.date}
  onChange={handleChange}
  style={{ borderColor: errors.date ? 'red' : '#ccc' }}
/>
{errors.date && (
  <span style={{ color: 'red', fontSize: 12 }}>{errors.date}</span>
)}

Écrire de bons messages : dire quoi corriger

Voici la partie que presque personne ne travaille — et c'est précisément pour ça qu'elle te distingue. Un message d'erreur a un seul travail : permettre à l'utilisateur de résoudre le problème, pas le constater. « Champ invalide » constate ; « le numéro doit contenir 10 chiffres, sans espaces » résout. Trois critères suffisent à juger n'importe quel message : dit-il quoi faire et pas seulement ce qui ne va pas ? est-il spécifique à ce champ ou interchangeable ? son ton est-il neutre, factuel, sans blâme ni humour condescendant ? On corrige plus vite quand on ne se sent pas accusé.

Deux subtilités. Le message d'un champ obligatoire gagne à dire pourquoi la donnée est demandée quand ce n'est pas évident : « Le email est requis » est correct, « Entre un email : c'est là qu'on envoie ta confirmation » est meilleur, parce qu'il transforme une contrainte en service rendu. Et évite absolument le vocabulaire de ton code : « le champ service_id est null » n'a de sens que pour toi — l'utilisateur ne sait pas que ton formulaire a des champs, encore moins qu'ils ont des identifiants.

L'état d'envoi complet : idle, submitting, success, error

Un envoi n'est pas un instant, c'est une durée, avec plusieurs issues. Les gestes de base sont acquis depuis Formulaires 1 — contrôlé ou non (preventDefault, la garde anti double-envoi, le finally) : ils réapparaissent ci-dessous sans être réexpliqués. Ce que ce module ajoute, c'est un modèle plus fin que le booléen isSubmitting : une petite machine à états, où le formulaire est à tout moment dans exactement un des quatre états suivants.

Pourquoi une seule variable à quatre valeurs plutôt que trois booléens (isLoading, isSuccess, isError) ? Parce que trois booléens permettent huit combinaisons, dont plusieurs sont absurdes : « en chargement ET en succès ET en erreur » est représentable, donc un jour ça arrivera. Avec une variable unique, les états impossibles sont littéralement impossibles à écrire — le principe porte un nom juste, « rendre les états invalides irreprésentables », et un type 'idle' | 'submitting' | 'success' | 'error' te le donne gratuitement, auto-complétion comprise.

type Status = 'idle' | 'submitting' | 'success' | 'error';

const [status, setStatus] = useState<Status>('idle');
const [formError, setFormError] = useState<string | null>(null);

async function handleSubmit(e: React.FormEvent<HTMLFormElement>) {
  e.preventDefault();          // on garde la main : pas de rechargement de page
  setSubmitAttempted(true);    // à partir d'ici, on montre TOUTES les errors

  // On revalide ICI, au moment du geste — sans réutiliser la variable `errors`
  // dérivée plus haut, pour ne pas la masquer avec un nom identique.
  const submitErrors = validateAppointment(values);
  if (Object.keys(submitErrors).length > 0) return;  // {} vide = valide, sinon on s'arrête

  // Garde-fou anti double-envoi : si une requête est déjà partie, on ignore.
  if (status === 'submitting') return;

  setStatus('submitting');
  setFormError(null);
  try {
    const res = await fetch('/api/appointments', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(values),
    });

    // LE fetch honnête : une réponse 400 ou 500 ne lève PAS d'exception.
    // Sans ce test, une erreur serveur passerait pour un succès.
    if (!res.ok) throw new Error(`Le serveur a répondu ${res.status}`);

    setStatus('success');
    setValues({ fullName: '', email: '', date: '', service: '' }); // on repart à neuf
    setTouched({});
    setSubmitAttempted(false);
  } catch {
    setStatus('error');
    setFormError("Impossible d'enregistrer le rendez-vous. Vérifie ta connexion et réessaie.");
  }
}

Le if (!res.ok) throw est le point le plus souvent raté — le « fetch honnête » du module HTTP & fetch : fetch ne rejette sa promesse que si la requête n'est jamais partie (réseau coupé, DNS mort). Un 400 ou un 500 arrive tranquillement dans le try, comme une réponse parfaitement normale.

Côté rendu, la machine à états pilote le bouton. Trois points à ne pas manquer : le disabled pendant l'envoi (la protection principale contre le double clic), le libellé qui change, et le message de succès en région live pour qu'il soit annoncé.

<button type="submit" disabled={status === 'submitting'}>
  {status === 'submitting' ? 'Envoi en cours…' : 'Réserver'}
</button>

{/* Succès et échec global : deux régions live, jamais les deux à la fois */}
{status === 'success' && (
  <p role="status" className="succes">
    Rendez-vous confirmé. Un email de confirmation vient de partir.
  </p>
)}
{status === 'error' && formError && (
  <p role="alert" className="erreur-globale">{formError}</p>
)}

role="status" pour le succès, role="alert" pour l'échec : deux régions live, mais alert est « assertif » (il interrompt la lecture) et status « poli » (il attend une pause). Un succès n'a pas à interrompre ; une erreur, si.

// --- CÔTÉ CLIENT ---
async function handleSubmit(e) {
  e.preventDefault();
  const errors = validate(values);
  if (Object.keys(errors).length) { setErrors(errors); return; }
  await fetch('/api/appointments', {
    method: 'POST',
    body: JSON.stringify(values),
  });
  alert('Rendez-vous confirmé !');
}

// --- CÔTÉ SERVEUR ---
export async function POST(request) {
  const data = await request.json();
  await db.appointments.create({ data });   // insertion directe
  return Response.json({ ok: true });
}

setStatus('submitting');
try {
  await fetch('/api/appointments', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(values),
  });
  setStatus('success');
  setValues(EMPTY);            // on repart à neuf
} catch {
  setStatus('error');
}

Typer une config : l'union discriminée

Le formulaire piloté par une configuration a été vu dans Formulaires 1 — contrôlé ou non. Ajoute-lui un bloc rules par champ (required, minLength, future) et la config décrit non plus seulement « quels champs », mais « à quelles conditions ils sont valides ». Reste une question : comment typer ça ? Un champ select a des options qu'un champ texte n'a pas, et une règle future n'a aucun sens ailleurs que sur une date. Le mauvais réflexe serait un seul type avec tout en facultatif — on perdrait toute vérification. Le bon outil s'appelle une union discriminée, et c'est la vraie leçon durable de ce patron.

Le principe : un type par variante, chacun contenant un champ commun dont la valeur est littérale et différente à chaque fois (ici type, valant 'text', 'email', 'date' ou 'select'). Ce champ est le discriminant : l'étiquette qui dit de quelle variante il s'agit. On fait ensuite l'union des variantes avec des |, et TypeScript devient capable de rétrécir le type tout seul : dans une branche if (field.type === 'select'), il sait que field.options existe, et il refuse d'y accéder ailleurs. C'est le mécanisme décortiqué dans Lire les types TypeScript — ici il travaille pour toi.

// Les règles possibles. Toutes facultatives : un champ n'en porte que certaines.
type Rules = {
  required?: boolean;
  minLength?: number;
  future?: boolean;      // n'a de sens que pour une date
};

type Base = { name: string; label: string; hint?: string; rules?: Rules };

// UNION DISCRIMINÉE : `type` est le discriminant. Chaque variante a sa forme.
export type FieldConfig =
  | (Base & { type: 'text' })
  | (Base & { type: 'email' })
  | (Base & { type: 'date' })
  | (Base & { type: 'select'; options: string[] });   // seul le select a options

export type FormConfig = { title: string; fields: FieldConfig[] };

Le gain est immédiat : écrire { type: 'text', options: [...] } devient une erreur de compilation, et oublier options sur un select aussi. Le type encode la règle « seul un select a des options » — plus besoin de la documenter, elle est vérifiée.

Les bibliothèques, honnêtement

Tout ce qu'on vient d'écrire à la main existe en version outillée. Il faut connaître ces bibliothèques — on te demandera si tu les as utilisées — mais surtout savoir pourquoi elles existent, sinon tu ne sauras jamais quand t'en passer.

react-hook-form

Le choix par défaut de l'écosystème React. Son idée centrale est astucieuse : plutôt que de mettre chaque champ en état contrôlé (un re-render du formulaire à chaque frappe), il travaille en mode non contrôlé — il enregistre les champs via des refs et lit leurs valeurs dans le DOM au moment voulu. Taper ne re-render donc presque rien, et sur trente champs la différence de fluidité est perceptible. Il apporte aussi, tout prêts, touched, isSubmitting, dirty (« modifié depuis le chargement »), les tableaux de champs dynamiques et le branchement d'un schéma de validation.

Zod (et son petit cousin Valibot)

Zod change la nature de l'exercice : au lieu d'écrire une fonction pleine de if, tu déclares un schéma, une description de la forme attendue des données. Le schéma devient la source de vérité unique et — le point vraiment fort — TypeScript peut en dériver le type. Tu n'as plus deux choses à garder synchronisées, tu en as une seule.

import { z } from 'zod';

export const appointmentSchema = z.object({
  fullName: z.string().trim().min(2, 'Le nom doit contenir au moins 2 caractères.'),
  email: z.string().email('Ce email semble incomplet. Exemple : nom@exemple.ca'),
  date: z.string().refine(
    (d) => new Date(d + 'T00:00') > new Date(),
    'Choisis une date à venir.'
  ),
  service: z.enum(['Physiothérapie', 'Ostéopathie', 'Massothérapie']),
});

// Le TYPE est DÉRIVÉ du schéma : une seule source de vérité, jamais de dérive.
export type AppointmentValues = z.infer<typeof appointmentSchema>;

// Côté client comme côté serveur, exactement le même appel :
const result = appointmentSchema.safeParse(data);
if (!result.success) {
  // result.error contient les messages, champ par champ
}

safeParse renvoie { success, data | error } au lieu de lever une exception — exactement la distinction Result-based vs throwing évoquée plus haut. Zod offre aussi parse, qui lance : un seul schéma, deux saveurs, l'interface prend la douce et l'écriture en base la brutale.

Formik

Formik a longtemps été la réponse aux formulaires React : contrôlé, plus verbeux, son développement est nettement moins actif. Tu dois savoir le lire dans du code existant, tu n'as pas de raison de démarrer un nouveau projet avec.

Alors, à la main ou en bibliothèque ?

Le critère honnête : trois ou quatre champs avec des règles simples, écris-le à la main — la bibliothèque coûte plus cher qu'elle ne rapporte (poids, API à apprendre, indirection pour le prochain lecteur). Un formulaire long, des champs conditionnels, des tableaux répétables, des règles croisées, ou dix formulaires dans la même application : react-hook-form + Zod, sans hésiter.

Mais voici ce qui compte pour toi : en entrevue et en test technique, on te demandera presque toujours de le faire à la main. Pas par nostalgie — c'est le seul moyen de vérifier que tu comprends ce que la bibliothèque fait à ta place. Qui ne sait qu'appeler useForm() est bloqué dès que le comportement par défaut ne convient pas ; qui a écrit un validateur pur, un état touched et une machine à quatre états comprend exactement ce que react-hook-form lui offre et peut argumenter son choix. C'est cette personne qu'on embauche.

export async function POST(request) {
  const body = await request.json();

  const result = appointmentSchema.safeParse(body);
  if (!result.success) {
    return Response.json({ error: 'Données invalides' }, { status: 400 });
  }

  await db.appointments.create({ data: { ...body, ...result.data } });
  return Response.json({ ok: true });
}