Les limites du JS natif

Avant de parler d'architecture et de react, il est important de comprendre pourquoi on a besoin de ces outils.
En JS natif (ou Vanilla JS), on manipule le DOM de manière impérative.
Cela veut dire qu'on explique au navigateur exactement comment faire chaque action, étape par étape.

On sélectionne un élément, on écoute un événement, puis on modifie manuellement le contenu ou le style de cet élément.

 /* On récupère l'élément html */
 const button = document.querySelector('#myButton');
 let count = 0;

 /* On attache un écouteur d'événement */
 button.addEventListener('click', () => {
  count++;
  /* On met à jour le dom manuellement */
  button.textContent = `cliqué ${count} fois`;
 });

Pour une petite interaction, ça fonctionne très bien.
Mais quand l'application grossit, la donnée (le state) est souvent affichée à plusieurs endroits en même temps dans l'interface (la UI).

Si on modifie cette donnée, on doit cibler et mettre à jour manuellement chaque nœud du DOM qui en dépend. La logique métier se retrouve mélangée à la manipulation visuelle, le code devient difficile à maintenir et l'interface finit souvent par se désynchroniser de la donnée.

Exercice

En utilisant uniquement du HTML et du JS natif, créer un mini-panier e-commerce pour expérimenter les limites de l'approche impérative.

L'utilisateur aura un bouton pour ajouter un article. Vous devrez synchroniser la donnée à plusieurs endroits différents.

En fonction du nombre de clics sur le bouton d'ajout, vous devrez :

• mettre à jour un compteur global affiché dans une balise header
• mettre à jour le texte du bouton cliqué pour inclure le nombre (ex: "ajouter (2)")
• afficher un texte "stock épuisé" dans une div séparée quand on atteint 5 articles
• désactiver le bouton en lui ajoutant l'attribut disabled quand on atteint 5 articles