Formulaires 1 — contrôlé ou non

Si tu ne devais maîtriser qu'un seul sujet avant ton prochain test technique, ce serait celui-ci. Le formulaire est l'exercice universel des entrevues frontend : il tient dans une heure, il touche à l'état, aux événements, à l'accessibilité et au réseau. Ce module pose les fondations : ce que le navigateur sait déjà faire tout seul, les deux manières de brancher React dessus (contrôlé et non contrôlé), et le patron qui gère vingt champs avec un seul gestionnaire. La validation a son propre module, juste après.

Le formulaire natif, avant même de parler de React

Avant de plonger dans React, il faut comprendre ce que le navigateur fait déjà : React ne remplace pas ce mécanisme, il se branche dessus. Beaucoup de candidats perdent des points ici, non parce qu'ils connaissent mal React, mais parce qu'ils n'ont jamais regardé un formulaire HTML tout nu.

Le formulaire est l'une des plus vieilles briques du web : bien avant JavaScript, le HTML savait déjà envoyer des données à un serveur. Le mécanisme n'a pas changé — tu enveloppes des champs dans un <form>, tu lui donnes une destination (action) et une méthode HTTP (method), et le navigateur prend le relais à la soumission.

<!-- Un formulaire 100 % natif : aucune ligne de JavaScript. -->
<form action="/rendez-vous" method="post">
  <label for="nom">Nom complet</label>
  <input id="nom" name="fullName" type="text" required />

  <label for="email">Courriel</label>
  <input id="email" name="email" type="email" required />

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

Ce formulaire fonctionne. Sans React, sans fetch, sans une seule ligne de JS. C'est le point de départ qu'il faut avoir en tête.

Ce qui se passe exactement à la soumission

Quand l'utilisateur clique sur « Réserver » (ou appuie sur Entrée dans un champ), le navigateur déroule une séquence très précise :

1. Il parcourt tous les champs et retient ceux qui ont un attribut name. Les autres sont purement et simplement ignorés.
2. Il construit une paire name / value pour chacun et les encode (par défaut en application/x-www-form-urlencoded, qui ressemble à fullName=Patrick&email=p%40exemple.ca).
3. Il envoie une vraie requête HTTP vers l'URL de action — en query string avec method="get", dans le corps avec method="post" (module HTTP & fetch).
4. Il remplace la page entière par la réponse du serveur.

Cette dernière étape est la clé. Le formulaire natif provoque une navigation complète : parfait pour le web « classique » de documents, catastrophique dans une single-page application, où recharger la page détruit tout l'état React en mémoire. Ton formulaire multi-étapes avec sa barre de progression et ses données saisies ? Effacé.

Pourquoi on intercepte : preventDefault

D'où le geste fondateur du formulaire en React : on intercepte l'événement de soumission et on annule le comportement par défaut du navigateur.

function handleSubmit(event) {
  event.preventDefault(); // ← on annule la navigation + le rechargement de page
  // À partir d'ici, c'est NOUS qui décidons quoi faire des données.
}

preventDefault() ne « bloque » pas l'événement : il dit « n'exécute pas ton action par défaut ». Le même mécanisme empêche un lien de naviguer.

Ce que le navigateur t'offre gratuitement

Deuxième chose qu'on sous-estime toujours : la richesse des champs natifs. En React Native, tu as TextInput et tu construis le reste. Sur le web, le navigateur te donne une boîte à outils déjà fournie, où chaque outil arrive avec des comportements gratuits que tu paierais cher à réimplémenter.

Dans presque chaque ligne, il y a un cadeau. Le clavier adapté sur mobile (type="email" fait apparaître la touche @, type="tel" ouvre le pavé numérique) est probablement le meilleur rapport qualité/effort de tout le développement web. La validation de base (required, min, maxlength, pattern) donne un premier filet sans une ligne de JS — on la creusera dans le module Formulaires 2 — validation & erreurs. Et l'autocomplétion (autocomplete="email", "tel", "name") laisse le navigateur et le gestionnaire de mots de passe remplir le formulaire d'un tap : gain de conversion énorme, coût nul.

<label for="nom">Nom complet</label>
<input id="nom" name="fullName" type="text"
       autocomplete="name" required />

<label for="email">Courriel</label>
<input id="email" name="email" type="email"
       autocomplete="email" required />

<label for="tel">Téléphone</label>
<input id="tel" name="phone" type="tel" autocomplete="tel" />

<label for="service">Service</label>
<select id="service" name="service">
  <option value="physio">Physiothérapie</option>
  <option value="massage">Massothérapie</option>
</select>

<label for="notes">Précisions (facultatif)</label>
<textarea id="notes" name="notes" rows="4"></textarea>

Le composant contrôlé : React devient la source de vérité

Passons à React. Un champ contrôlé est un champ dont la valeur affichée est entièrement dictée par l'état React. On le reconnaît à deux attributs qui vont toujours ensemble : value et onChange.

import { useState } from 'react';

export function NameField() {
  // L'état React détient la valeur du champ. C'est LUI la vérité.
  const [fullName, setFullName] = useState('');

  return (
    <>
      <label htmlFor="nom">Nom complet</label>
      <input
        id="nom"
        name="fullName"
        value={fullName}                                  // ① ce qui s'affiche vient de l'état
        onChange={(e) => setFullName(e.target.value)}      // ② toute frappe met l'état à jour
      />
      {/* Puisque l'état est la vérité, on peut l'afficher ailleurs en direct. */}
      <p>Bonjour {fullName || 'inconnu'} — {fullName.length} caractères</p>
    </>
  );
}

Note htmlFor au lieu de for, mot réservé de JavaScript — l'un des deux décalages HTML/JSX vus dans le module React web ↔ React Native.

Le cycle complet, frappe par frappe

Il faut absolument que tu puisses dérouler cette boucle à voix haute en entrevue. fullName vaut "Patr", l'utilisateur tape i : (1) le navigateur insère provisoirement le caractère dans le champ du DOM ; (2) il émet un événement input que React, à l'écoute depuis la racine, transforme en appel de ton onChange — e.target.value vaut "Patri" ; (3) setFullName("Patri") note la demande ; (4) React rappelle NameField, dont le JSX produit cette fois <input value="Patri" /> ; (5) React écrit "Patri" dans le champ réel.

Le point à saisir, et il est contre-intuitif : à l'étape 5, React réécrit la valeur du champ, même si elle est déjà correcte. Il ne « laisse pas » le caractère que l'utilisateur a tapé — il l'impose depuis l'état. La lettre que tu vois à l'écran n'est pas celle que tu as tapée : c'est celle que React a décidé d'afficher, après un aller-retour complet par l'état. C'est exactement ce qu'on veut dire par « React est la source de vérité ». Conséquence merveilleuse : puisque la valeur passe par ton code à chaque frappe, tu peux la transformer au passage (majuscules forcées, masque de téléphone, compteur de caractères, bouton activé ou non). Conséquence coûteuse : chaque frappe provoque un re-render du composant — indolore sur un champ isolé, perceptible sur un formulaire de quarante champs.

const [fullName, setFullName] = useState('');

return <input value={fullName} />;

Le composant non contrôlé : on laisse le DOM faire son travail

L'autre approche consiste à… ne rien faire. Le champ se débrouille comme en HTML pur : le DOM garde la valeur, React ne re-render pas, et on lit la valeur seulement au moment où on en a besoin — typiquement à la soumission. Pour une valeur de départ sans prendre le contrôle, on utilise defaultValue (et defaultChecked pour les cases et les radios), lu au premier rendu seulement, comme la valeur initiale de useState : le changer plus tard ne modifie pas le champ.

import { useRef } from 'react';

export function SimpleForm() {
  // useRef = une boîte stable qui ne provoque AUCUN re-render quand on la change.
  const nameRef = useRef<HTMLInputElement>(null);

  function handleSubmit(e: React.FormEvent) {
    e.preventDefault();
    // On va CHERCHER la valeur dans le DOM, au moment précis où on en a besoin.
    const fullName = nameRef.current?.value ?? '';
    console.log('Nom saisi :', fullName);
  }

  return (
    <form onSubmit={handleSubmit}>
      <label htmlFor="nom">Nom complet</label>
      {/* Pas de `value`, pas de `onChange` : zéro re-render pendant la frappe. */}
      <input id="nom" name="fullName" ref={nameRef} defaultValue="" />
      <button type="submit">Réserver</button>
    </form>
  );
}

useRef te donne une poignée vers l'élément DOM réel — même outil que pour déplacer le focus dans le module useState & useEffect, autre usage. La règle ne change pas : useRef pour ce qu'on retient sans redessiner.

Quand le non contrôlé est le bon choix

Le non contrôlé a mauvaise presse chez les débutants, qui l'ont appris comme « la vieille façon ». C'est faux, et le dire en entrevue est un excellent signal de maturité. C'est le bon choix quand :

• Le formulaire est simple et rien ne se passe pendant la frappe. Un « nom, email, message, envoyer » n'a aucune raison de re-render à chaque lettre.
• Le formulaire est gros. Trente champs contrôlés dans un seul composant : chaque frappe redessine les trente, plusieurs fois par seconde en frappe rapide. Le non contrôlé rend ce coût nul, React étant absent de la boucle.
• Le champ est un type="file". Pas le choix : pour des raisons de sécurité, la valeur d'un champ fichier ne peut pas être fixée par JavaScript. Il est toujours non contrôlé.
• Tu intègres une librairie non-React (éditeur de texte riche, widget de carte) qui gère son propre DOM.

Et il est le mauvais choix dès que l'interface doit réagir pendant la frappe :

• Bouton d'envoi désactivé tant que le formulaire est incomplet.
• Compteur de caractères restants, jauge de force du mot de passe.
• Recherche instantanée qui filtre une liste à chaque lettre.
• Formatage en direct (masque de téléphone, séparateurs de milliers).
• Message d'erreur qui apparaît et disparaît au fil de la saisie.
• Un champ dont la valeur dépend d'un autre champ (choisir un service change les créneaux).

La ligne de partage n'a rien à voir avec la taille du formulaire ni avec la mode. Elle tient en une question : est-ce que quelque chose à l'écran doit changer entre deux frappes ? Si oui, contrôlé. Si non, laisse le DOM tranquille.

<input value={patient.email} />
<input defaultValue={patient.email} />

FormData : lire tout le formulaire d'un coup

Une ref par champ, ça va pour deux champs ; à dix, c'est fastidieux. Le navigateur a heureusement l'outil qu'il faut depuis longtemps — c'est même lui qui s'en sert pour envoyer les formulaires natifs : FormData.

function handleSubmit(e: React.FormEvent<HTMLFormElement>) {
  e.preventDefault();

  // currentTarget = l'élément sur lequel le gestionnaire est posé, donc le <form>.
  const formData = new FormData(e.currentTarget);

  // FormData est itérable : Object.fromEntries en fait un objet ordinaire.
  const values = Object.fromEntries(formData);
  // → { fullName: 'Patrick', email: 'p@exemple.ca', service: 'physio', notes: '' }

  console.log(values);
}

Deux lignes pour récupérer l'intégralité d'un formulaire, quel que soit son nombre de champs. C'est la manière moderne, et elle impressionne en entrevue parce qu'elle montre que tu connais la plateforme, pas seulement React.

new FormData(unFormulaire) collecte tous les champs qui ont un name — littéralement le même algorithme que le navigateur dans la section « Le formulaire natif, avant même de parler de React ». D'où l'importance capitale de cet attribut : sans name, un champ est invisible pour FormData. C'est l'oubli numéro un, et il est vicieux — le champ s'affiche et se remplit parfaitement, puis disparaît au moment de l'envoi.

Deux subtilités, questions pièges classiques :

• Une case à cocher non cochée est simplement absente de FormData — pas false, absente ; cochée sans attribut value, elle vaut la chaîne "on". On teste donc avec formData.has('newsletter').
• Object.fromEntries écrase les doublons. Si plusieurs champs partagent le même name (groupe de cases, <select multiple>), tu ne gardes que le dernier : utilise formData.getAll('nomDuChamp'), qui renvoie un tableau.

Sois honnête sur ce tableau en entrevue : FormData n'est pas « mieux », il est différent — il gagne sur la concision et la performance, il perd sur le typage et la réactivité. Un développeur expérimenté choisit selon le besoin ; un débutant applique toujours la même recette.

function handleSubmit(e) {
  e.preventDefault();
  const values = Object.fromEntries(new FormData(e.currentTarget));
  send(values);   // → { fullName: 'Patrick', email: 'p@exemple.ca' }
}

return (
  <form onSubmit={handleSubmit}>
    <input name="fullName" />
    <input name="email" type="email" />
    <textarea id="notes" value={notes} onChange={(e) => setNotes(e.target.value)} />
    <button type="submit">Réserver</button>
  </form>
);

Un seul état pour plusieurs champs

Revenons au contrôlé, pour résoudre son problème le plus visible : l'explosion du code. Cinq champs, cinq useState — c'est ce que fait l'écran d'inscription d'Halterofit, et c'est très bien. Mais à quinze champs, tu as quinze états et quinze fonctions fléchées quasi identiques. La parade, le patron à mémoriser de ce module : un seul état sous forme d'objet où chaque clé porte le name d'un champ, et un seul gestionnaire qui se sert de ce name pour savoir quelle clé mettre à jour.

const [values, setValues] = useState({});

const handleChange = (e) =>
  setValues({ ...values, [e.target.name]: e.target.value });

Décortiquer la formule

L'objet-état et le { ...state, [k]: v }, tu les écris déjà tous les jours avec Zustand. Deux détails méritent quand même un arrêt. La clé calculée [e.target.name] d'abord : les crochets, dans un littéral d'objet, signifient « évalue cette expression et utilise le résultat comme nom de clé ». Sans eux, { name: 'Patrick' } crée une clé littéralement appelée name ; avec eux, { [name]: 'Patrick' } crée une clé appelée ce que contient la variable — donc fullName ou email selon le champ qui a déclenché l'événement. C'est du JavaScript standard, pas du React, et c'est ce qui permet à un seul handler de servir tout le formulaire.

L'ordre du spread ensuite — le seul vrai piège : ce qui vient après l'étalement gagne. { [e.target.name]: e.target.value, ...values } laisse l'ancien objet écraser ta nouvelle valeur, et rien ne change jamais. Un bug redoutable, parce qu'il ressemble à du code correct.

type Values = {
  fullName: string; email: string; phone: string;
  service: string; notes: string;
};

const EMPTY: Values = { fullName: '', email: '', phone: '', service: 'physio', notes: '' };

export function AppointmentForm() {
  const [values, setValues] = useState<Values>(EMPTY);

  // UN SEUL gestionnaire pour les 5 champs, grâce à l'attribut `name`.
  const handleChange = (
    e: React.ChangeEvent<HTMLInputElement | HTMLSelectElement | HTMLTextAreaElement>,
  ) => setValues({ ...values, [e.target.name]: e.target.value });

  return (
    <form onSubmit={handleSubmit}>
      <input name="fullName" value={values.fullName} onChange={handleChange} />
      <input name="email" type="email" value={values.email} onChange={handleChange} />
      <input name="phone" type="tel" value={values.phone} onChange={handleChange} />
      <select name="service" value={values.service} onChange={handleChange}>
        <option value="physio">Physiothérapie</option>
        <option value="massage">Massothérapie</option>
      </select>
      <textarea name="notes" value={values.notes} onChange={handleChange} />
      <button type="submit">Réserver</button>
    </form>
  );
}

const handleChange = (e) => {
  values[e.target.name] = e.target.value;
  setValues(values);
};

Le submit : intercepter, envoyer, réinitialiser

On a les données. Reste à les envoyer correctement — et c'est là que se joue une bonne moitié des points d'un test technique, parce que c'est là qu'on distingue le code « ça marche sur ma machine » du code qu'on met en production.

onSubmit sur le <form>, jamais onClick sur le bouton

Règle numéro un, et question d'entrevue la plus fréquente du sujet. Beaucoup de débutants écrivent <button onClick={handleSubmit}> : ça a l'air de fonctionner, c'est pourtant un bug, pour plusieurs raisons cumulées.

• La touche Entrée. Le navigateur implémente la soumission implicite : appuyer sur Entrée depuis n'importe quel champ texte déclenche le submit. C'est le geste par défaut de tout utilisateur habitué, et il ne passe jamais par le onClick de ton bouton. Ton gestionnaire n'est donc pas appelé, mais l'action par défaut du navigateur, elle, s'exécute : la page se recharge et tout est perdu.
• La validation native. Les attributs comme required ne sont vérifiés qu'au moment du submit. Un onClick court-circuite ce contrôle et rend tes attributs de validation décoratifs.
• L'accessibilité, l'assistance et les frameworks. Lecteurs d'écran, gestionnaires de mots de passe, outils d'autoremplissage, librairies de formulaires et Server Actions de Next.js se branchent tous sur l'événement submit d'un vrai formulaire. Un onClick te coupe de tout cet écosystème.

La bonne structure est donc toujours la même : <form onSubmit={handleSubmit}> avec, à l'intérieur, un <button type="submit">. Et méfie-toi d'un détail : dans un <form>, un <button> sans attribut type vaut type="submit". Un bouton « Annuler » ou « Ajouter une ligne » doit donc porter type="button" — sinon il soumet le formulaire, et tu passeras un temps fou à comprendre pourquoi « Annuler » envoie la réservation.

Le gestionnaire, dans sa version la plus simple

async function handleSubmit(e: React.FormEvent<HTMLFormElement>) {
  e.preventDefault();   // ① le geste sans lequel la page se recharge
  await sendAppointment(values);
  setValues(EMPTY);     // ② reset : on repart d'un objet COMPLET, pas de {}
}

Le chemin heureux, et rien d'autre : on intercepte, on envoie, on remet à zéro.

Ces deux lignes suffisent tant que tout se passe bien — et c'est précisément leur limite. Elles ne disent rien de ce qui arrive quand le serveur répond 500, quand le réseau tombe, ou quand l'utilisateur reclique parce qu'il ne voit rien bouger. Ces questions-là ne relèvent pas de la collecte des valeurs, qui est le sujet de ce module, mais de l'issue de l'envoi : c'est tout le propos du module Formulaires 2 — validation & erreurs, qui reprend exactement ce gestionnaire et lui ajoute la garde anti double-envoi, la vérification de res.ok et les quatre états d'une soumission. La ligne de partage est là : ici on récolte, là-bas on juge et on encaisse l'échec.

Réinitialiser après un succès

Trois techniques, par ordre de préférence :

1. Formulaire contrôlé : remets l'état à sa valeur initiale. setValues(EMPTY) — et surtout pas setValues({}), pour la raison exposée dans l'encadré « le champ qui change de camp ». Propre, explicite, testable.
2. Formulaire non contrôlé : e.currentTarget.reset(), la méthode native du <form>. Attention après un await : React recycle les objets événement et e.currentTarget peut être devenu null — garde une référence dans une variable avant.
3. Le truc de la key. Changer la key d'un élément dit à React « ce n'est plus le même » : il démonte l'ancien sous-arbre et en monte un neuf, états frais compris. Avec un compteur formKey incrémenté après chaque succès, <AppointmentForm key={formKey} /> se réinitialise intégralement — y compris les états internes des composants enfants qu'on ne contrôle pas.

// Ce compteur vit dans le PARENT du formulaire : c'est lui qui tient la clé.
const [formKey, setFormKey] = useState(0);

// L'enfant prévient son parent quand l'envoi a réussi ; le parent incrémente
// la clé. Nouvelle clé = autre élément aux yeux de React : il jette l'ancien
// formulaire et en monte un neuf, tous les états remis à zéro.
return <AppointmentForm key={formKey} onSuccess={() => setFormKey((k) => k + 1)} />;

Le « remontage par la key » est une technique officielle, pas un bricolage. Très utile en édition : key={patientId} et le formulaire se réinitialise seul quand on change de patient, sans le moindre useEffect.

async function handleSubmit(e) {
  const res = await fetch('/api/appointments', {
    method: 'POST',
    body: JSON.stringify(values),
  });
  setConfirmed(true);
}

return (
  <form onSubmit={handleSubmit}>
    {/* ... champs ... */}
    <button type="submit">Réserver</button>
  </form>
);

Le formulaire piloté par des données

Voici l'exercice que tu as de bonnes chances de rencontrer tel quel : « on te donne une configuration JSON qui décrit des champs, génère le formulaire ». Le principe : décrire chaque champ comme un objet de données (type, name, libellé) au lieu de l'écrire à la main dans le JSX. Le formulaire devient une fonction de sa configuration, et peut donc venir d'une API ou d'un CMS et évoluer sans redéploiement.

[
  { "type": "text",     "name": "fullName", "label": "Nom complet",  "required": true },
  { "type": "email",    "name": "email",    "label": "Courriel",     "required": true },
  { "type": "tel",      "name": "phone",    "label": "Téléphone" },
  { "type": "date",     "name": "date",     "label": "Date souhaitée" },
  { "type": "select",   "name": "service",  "label": "Service",
    "options": [
      { "value": "physio",  "label": "Physiothérapie" },
      { "value": "massage", "label": "Massothérapie" }
    ] },
  { "type": "textarea", "name": "notes",    "label": "Précisions" },
  { "type": "checkbox", "name": "rappel",   "label": "M'envoyer un rappel la veille" }
]

Sept champs décrits en données. Ajouter un champ, c'est ajouter une ligne ici — pas toucher au composant.

Le composant qui rend cette config tient en trois idées. Un switch sur field.type, dont chaque branche produit le bon élément — dont la case à cocher, seul cas particulier, qui se lit dans checked et non dans value. Une branche default qui est le trait de génie du patron : pour tous les champs qui sont de simples <input>, la chaîne de configuration est l'attribut type du HTML, donc prendre en charge "password" ou "url" ne demande aucune ligne de code — juste d'élargir le type TypeScript. Et key={field.name} sur la boucle plutôt que l'index : un name est unique et stable par nature, un index change dès que la liste est filtrée ou réordonnée. Détail final qui vaut des points en test technique : construis l'état initial depuis la config (useState(() => Object.fromEntries(...))) — toutes les clés existent dès le premier rendu, ce qui t'immunise contre le piège du contrôlé/non contrôlé.

const handleChange = (e) =>
  setValues({ ...values, [e.target.name]: e.target.value });

<input
  type="checkbox"
  name="reminder"
  checked={values.reminder}
  onChange={handleChange}
/>

Contrôlé ou non : trancher, et savoir le dire

On revient à la question du début. Voici le tableau de décision à garder en tête ; il couvre à peu près toutes les situations que tu rencontreras.

Et une nuance qu'on oublie souvent : ce n'est pas un choix « tout ou rien ». Un champ de recherche contrôlé peut très bien vivre au milieu d'un formulaire par ailleurs non contrôlé lu avec FormData. Le contrôle se décide champ par champ.

const [values, setValues] = useState({});

<input
  name="email"
  value={values.email}
  onChange={(e) => setValues({ ...values, email: e.target.value })}
/>