JavaScript

Sie speichern eine Datei, Prettier formatiert sie neu, und ESLint meldet sofort einen Fehler in der Zeile, die Prettier gerade angefasst hat. Beide Tools sind konfiguriert, beide laufen, und statt zu helfen, bekämpfen sie sich gegenseitig. Die beiden Tools erledigen unterschiedliche Aufgaben. Das Problem: Beide haben eine Meinung zu genau einer Sache — wie der Code auf der Seite aussieht. Was ESLint tatsächlich prüft ESLint zerlegt Ihren Code in einen abstrakten Syntaxbaum und führt Regeln gegen dessen Struktur aus. Der größte Teil seines Nutzens kommt von Regeln, die echte Bugs finden: eine Variable, die nie definiert wird, ein nicht erreichbares return nach einem anderen return, ein ungenutzter Import, der nach einem Refactoring übrig blieb, ein doppelter Objekt-Key, der den ersten lautlos überschreibt. Das sind semantische Prüfungen — ESLint liest, was der Code tut. ...

Eine Chat-Komponente baut ihre WebSocket-Verbindung jedes Mal neu auf, wenn Sie einen Buchstaben in ein Suchfeld eingeben, das mit dem Chat nichts zu tun hat. Eine andere Komponente rendert sich in einer Schleife neu, bis der Tab einfriert. Eine dritte loggt beim Mount zweimal aus ihrem useEffect, aber nur in der Entwicklung. Keiner dieser Fälle ist ein React-Bug. Die ersten beiden sind das Dependency-Array, das genau das tut, was Sie ihm gesagt haben, und der dritte ist der Strict Mode, der prüft, ob Ihr Effekt sich selbst aufräumen kann. ...

<.+> gegen <b>bold</b> and <i>italic</i> findet nicht <b>. Es findet die gesamte Zeichenkette, vom ersten < bis zum allerletzten >. Nichts ist defekt. Genau das soll ein greedy Quantifizierer tun, und es ist auch der häufigste “Regex matcht zu viel”-Bug überhaupt. Sobald klar ist, was die Engine beim Lesen des Musters tut, hören dieser Bug und die meisten seiner Verwandten auf, Rätsel zu sein. Wie eine Regex-Engine Ihr Muster Liest Eine Regex-Engine vergleicht Ihr Muster nicht mit der Zeichenkette wie man zwei Zeichenketten auf Gleichheit vergleicht. Die Engines, die Sie täglich nutzen (re in Python, RegExp in JavaScript, PCRE, .NET, Java), sind regex-directed: Sie lesen das Muster von links nach rechts, Token für Token, und versuchen für jedes Token, Zeichen aus der Zeichenkette an der aktuellen Position zu konsumieren. Wenn ein Token passt, rückt die Engine sowohl den Muster-Zeiger als auch den Zeichenketten-Zeiger vor. Wenn ein Token fehlschlägt, macht die Engine Backtracking: Sie geht zum letzten Punkt zurück, an dem sie eine Wahl hatte, etwa ein Quantifizierer, der weniger Zeichen hätte matchen können, oder ein noch nicht probierter Alternationszweig, und probiert die andere Option. ...

Warum geht der übergebene Typ bei any verloren? Wenn Sie einen Parameter als any typisieren, prüft TypeScript nichts mehr von dem, was aus der Funktion kommt: 1 2 3 4 5 6 function firstElement(arr: any[]): any { return arr[0]; } const n = firstElement([1, 2, 3]); n.toUpperCase(); // compiliert, stürzt zur Laufzeit ab Sie wissen, dass Sie ein Array von Zahlen übergeben haben. Der Compiler weiß es nicht, weil any ihm sagt, nicht mehr hinzusehen. n kommt als any zurück, also compiliert der Aufruf einer String-Methode auf einer Zahl klaglos und wirft beim Ausführen TypeError: n.toUpperCase is not a function. ...

Ein scroll-Listener auf window kann während eines einzigen Swipes hunderte Male auslösen. Wer bei jedem dieser Events getBoundingClientRect() für jede Karte in einem Feed aufruft, braucht nur fünfzig Bilder, um die Seite ins Stottern zu bringen. Die Intersection Observer API nimmt diese Prüfung aus dem Scroll-Pfad: Sie registrieren, welche Elemente beobachtet werden sollen, und der Browser meldet sich, wenn sich deren Sichtbarkeit tatsächlich ändert. Wie IntersectionObserver funktioniert Ein Observer beobachtet ein oder mehrere Target-Elemente relativ zu einem Root (standardmäßig der Viewport) und ruft einen Callback auf, sobald ein Target einen Sichtbarkeitsschwellenwert überschreitet. ...

Was ist eine Closure in 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 läuft einmal, gibt eine Funktion zurück, und damit ist es erledigt: Der Stack-Frame existiert nicht mehr. Trotzdem liest und aktualisiert jeder Aufruf von counter() weiterhin count, eine Variable, die innerhalb einer bereits beendeten Funktion deklariert wurde. count wird nicht auf 0 zurückgesetzt und nicht kopiert. Es ist dieselbe Variable, immer noch lebendig, drei Aufrufe später. ...

Führen Sie in einem Projekt npm install aus und danach für dieselbe package.json pnpm install. Sie erhalten zwei unterschiedliche node_modules-Bäume und zwei unterschiedliche Lockfiles. Kommt ein Kollege dazu, der Yarn nutzt, landet das Repository mit drei Lockfiles in seiner Historie, jeder mit einem leicht anderen Abhängigkeitsbaum. Alle drei lesen dieselbe package.json und laden aus derselben npm-Registry. Uneinig sind sie sich darüber, was auf die Festplatte geschrieben wird. Wie npm, Yarn und pnpm node_modules aufbauen Die Struktur von npm ist flach. Jedes Paket, das Ihre Abhängigkeiten brauchen, egal wie tief im Baum, wird in die oberste node_modules gehoben, solange kein Versionskonflikt besteht. Das ist seit npm 3 das Standardverhalten. Der Nebeneffekt: Ihr Code kann ein Paket per require() oder import laden, das Sie nie in package.json eingetragen haben, solange etwas anderes im Baum davon abhängt. Das funktioniert, bis dieses andere Paket die Abhängigkeit in einem Minor-Release fallenlässt und Ihr Build bricht, ohne dass Sie Ihren eigenen Code geändert hätten. Das ist eine Phantom-Abhängigkeit, und die Struktur von npm tut nichts, um sie zu verhindern. ...

Packen Sie einen fetch()-Aufruf in ein try/catch, rufen Sie einen Endpunkt auf, der mit 404 antwortet, und der catch-Block läuft nie. Das Promise wird aufgelöst. res.json() parst, was auch immer der Server zurückgeschickt hat, oft ein Fehler-Payload wie {"error": "user not found"}, und der Rest der Funktion behandelt es als den angeforderten Datensatz. Keine Exception, keine Konsolenwarnung. Die falschen Daten wandern weiter, bis etwas anderes daran zerbricht. 1 2 3 4 5 6 7 8 9 async function getUser(id) { try { const res = await fetch(`/api/users/${id}`); const user = await res.json(); return user; // bei einem 404 ist das { error: "user not found" } } catch (err) { console.error('Failed to load user:', err); } } Dieses catch greift nur bei einer Anfrage, die nie abgeschlossen wird. Alles andere braucht eine Prüfung, die Sie selbst schreiben müssen. ...

Ein Suchfeld, das bei jedem Tastendruck eine Anfrage auslöst, schickt für “redis” fünf Anfragen, von denen vier veraltet sind, bevor die Antwort zurückkommt. Ein scroll-Handler, der das Layout neu berechnet, läuft hunderte Mal pro Sekunde und lässt die Seite stottern. Beide Fälle haben dasselbe Problem: Das DOM-Event feuert viel öfter, als der Handler laufen muss. Debounce und Throttle lösen das auf zwei unterschiedliche Arten. Was Debounce macht und was Throttle macht Debounce wartet, bis das Event für eine festgelegte Zeit nicht mehr feuert, und läuft dann einmal. Jeder neue Aufruf setzt die Uhr zurück. Hört das Event nie auf, läuft die Funktion nie. Ein Suchfeld ist der klassische Fall: warten, bis der Nutzer beim Tippen pausiert, und dann eine Anfrage für das zuletzt Eingegebene schicken. ...

Ein Login-Endpunkt liefert ein JWT zurück, und Sie haben drei Orte, um es abzulegen: ein Cookie, localStorage oder sessionStorage. Wählen Sie den falschen, und entweder trägt ein XSS-Bug das Token davon, oder das Token erreicht Ihre API nie. Alle drei speichern Strings im Browser. Sie unterscheiden sich darin, wer sie lesen kann, wie lange sie bestehen und ob der Server sie überhaupt zu sehen bekommt. Worin sich localStorage, sessionStorage und Cookies unterscheiden localStorage und sessionStorage sind dieselbe API, das Storage-Interface: setItem, getItem, removeItem, clear, String-Keys und String-Werte. Der Unterschied liegt in der Lebensdauer. localStorage überlebt das Schließen des Browsers und einen Neustart der Maschine und bleibt bestehen, bis etwas es löscht. Safari ist die Ausnahme: Mit aktivierter Tracking-Prevention löscht es skriptgeschriebenen Speicher für eine Seite, mit der der Nutzer seit sieben Tagen nicht interagiert hat. sessionStorage gehört einem einzelnen Tab und stirbt, wenn dieser Tab geschlossen wird. Geben Sie dieselbe URL in einem zweiten Tab ein, bekommen Sie ein frisches, leeres sessionStorage; nur “Tab duplizieren” kopiert den Inhalt mit. ...