JavaScript

Vous enregistrez un fichier, Prettier le reformate, et ESLint signale immédiatement une erreur sur la ligne que Prettier vient de toucher. Les deux outils sont configurés, les deux tournent, et au lieu de vous aider, ils se bloquent l’un l’autre. Les deux outils ne font pas le même travail. Le problème, c’est qu’ils ont tous les deux un avis sur une seule chose : l’apparence du code à l’écran. Ce qu’ESLint vérifie réellement ESLint transforme votre code en arbre de syntaxe abstraite et exécute des règles sur sa structure. Son intérêt principal vient des règles qui détectent de vrais bugs : une variable jamais définie, un return inaccessible après un autre return, un import resté inutilisé après un refactoring, une clé d’objet dupliquée qui écrase silencieusement la première. Ce sont des vérifications sémantiques : ESLint lit ce que le code fait. ...

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. ...

<.+> appliqué à <b>bold</b> and <i>italic</i> ne trouve pas <b>. Il trouve la chaîne entière, du premier < au tout dernier >. Rien n’est cassé. C’est exactement ce qu’un quantificateur greedy est censé faire, et c’est aussi le bug le plus courant de “mon regex matche trop”. Une fois que vous savez ce que fait le moteur pendant qu’il lit votre motif, ce bug et la plupart de ses cousins arrêtent d’être des mystères. ...

Pourquoi any fait-il perdre le type que vous avez passé ? Typez un paramètre en any et TypeScript arrête de vérifier tout ce qui sort de la fonction : 1 2 3 4 5 6 function firstElement(arr: any[]): any { return arr[0]; } const n = firstElement([1, 2, 3]); n.toUpperCase(); // compile, plante à l'exécution Vous savez que vous avez passé un tableau de nombres. Le compilateur, non, car any lui dit d’arrêter de regarder. n est de type any, donc appeler une méthode de string sur un number compile sans problème et lève TypeError: n.toUpperCase is not a function à l’exécution. ...

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. ...

Lancez npm install sur un projet, puis pnpm install sur le même package.json : vous obtenez deux arborescences node_modules différentes et deux lockfiles différents. Ajoutez un collègue qui utilise Yarn, et le dépôt finit avec trois lockfiles dans son historique, chacun décrivant une arborescence de dépendances légèrement différente. Les trois lisent le même package.json et téléchargent depuis le même registre npm. Ce sur quoi ils ne sont pas d’accord, c’est ce qu’il faut écrire sur le disque. ...

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. ...

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. ...