Vous écrivez .sidebar .card { color: blue; }, vous chargez la page, et la carte reste rouge à cause d’une règle ajoutée une heure plus tôt : .card { color: red; }. Votre nouvelle règle arrive plus tard dans le fichier. Elle perd quand même. Le navigateur compare les deux sélecteurs avec un système de points fixe, et .sidebar .card obtient un score plus élevé que .card, peu importe lequel a été écrit en dernier. ...
Un composant de chat reconnecte son WebSocket chaque fois que vous tapez une lettre dans un champ de recherche qui n’a rien à voir avec le chat. Un autre composant se re-render en boucle jusqu’à ce que l’onglet se bloque. Un troisième affiche son useEffect deux fois au montage, mais seulement en développement. Aucun de ces cas n’est un bug de React. Les deux premiers sont le tableau de dépendances qui fait exactement ce que vous lui avez demandé, et le troisième est Strict Mode qui vérifie que votre effet sait se nettoyer après lui-même. ...
Un listener scroll sur window peut se déclencher des centaines de fois pendant un seul swipe. Si vous exécutez getBoundingClientRect() sur chaque carte d’un feed à chacun de ces événements, cinquante images suffisent à faire ralentir la page. L’Intersection Observer API retire cette vérification du scroll : vous enregistrez les éléments à observer, et le navigateur vous prévient quand leur visibilité change réellement. Comment fonctionne IntersectionObserver Un observer surveille un ou plusieurs éléments target par rapport à un root (le viewport, par défaut) et appelle une callback chaque fois qu’un target franchit un seuil de visibilité. ...
Qu’est-ce qu’une closure en JavaScript ? 1 2 3 4 5 6 7 8 9 10 11 12 function makeCounter() { let count = 0; return function () { count += 1; return count; }; } const counter = makeCounter(); console.log(counter()); // 1 console.log(counter()); // 2 console.log(counter()); // 3 makeCounter s’exécute une fois, renvoie une fonction, et c’est tout : son stack frame n’existe plus. Pourtant, chaque appel à counter() lit et met à jour count, une variable déclarée à l’intérieur d’une fonction déjà terminée. count ne revient pas à 0, et n’est pas copiée. C’est la même variable, toujours vivante, trois appels plus tard. ...
Enveloppez un appel fetch() dans un try/catch, ciblez un endpoint qui renvoie un 404, et le bloc catch ne s’exécute jamais. La promise se résout. res.json() analyse le corps renvoyé par le serveur, souvent un payload d’erreur du type {"error": "user not found"}, et le reste de la fonction le traite comme l’enregistrement demandé. Aucune exception, aucun avertissement dans la console. La mauvaise donnée continue son chemin jusqu’à ce qu’autre chose se casse à cause d’elle. ...
Vous construisez un dashboard : un header, une sidebar, une zone de contenu principal, un footer. Vous partez sur Flexbox parce que c’est l’outil de mise en page que vous connaissez, et vingt minutes plus tard vous avez trois conteneurs display: flex imbriqués, une sidebar qui ne garde sa largeur qu’avec un nombre magique, et un footer qui flotte à mi-hauteur de la page quand le contenu est court. Rien de tout cela n’est un bug de Flexbox. Vous utilisez un outil à une dimension sur un problème à deux dimensions. ...
Un champ de recherche qui envoie une requête à chaque frappe en envoie cinq pour “redis”, et quatre arrivent périmées avant que la réponse ne revienne. Un handler de scroll qui recalcule le layout s’exécute des centaines de fois par seconde et fait saccader la page. Même problème dans les deux cas : l’événement du DOM se déclenche bien plus souvent que ce dont le handler a besoin. Debounce et throttle règlent ça de deux façons différentes. ...
Un endpoint de login vous renvoie un JWT, et vous avez trois endroits où le stocker : un cookie, localStorage, ou sessionStorage. Faites le mauvais choix et soit une faille XSS embarque le token avec elle, soit le token n’arrive jamais jusqu’à votre API. Les trois stockent des chaînes de caractères dans le navigateur. Ce qui change, c’est qui peut les lire, combien de temps elles survivent, et si le serveur les voit un jour. ...
Votre frontend tourne sur http://localhost:5173, votre API sur http://localhost:4000, et l’appel fetch qui fonctionnait sans problème dans Postman échoue dans le navigateur avec un mur de texte rouge : Access to fetch at 'http://localhost:4000/api/users' from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Votre serveur a très bien pu traiter cette requête et renvoyer un 200. Le navigateur, lui, a refusé de transmettre la réponse à votre JavaScript. ...