Web Development

Sie schreiben .sidebar .card { color: blue; }, laden die Seite, und die Card ist immer noch rot — wegen einer Regel, die Sie eine Stunde vorher hinzugefügt haben: .card { color: red; }. Ihre neue Regel steht später in der Datei. Sie verliert trotzdem. Der Browser vergleicht die beiden Selektoren mit einem festen Punktesystem, und .sidebar .card erhält eine höhere Punktzahl als .card, egal welcher zuletzt geschrieben wurde. Dieses Punktesystem ist die Spezifität. Sobald Sie sie auf den ersten Blick berechnen können, wird “warum wirkt mein CSS nicht” zu Arithmetik. Mit dem Layout hat das nichts zu tun: Grid oder Flexbox entscheidet, wo ein Element sitzt; die Spezifität entscheidet, welche Regel Farbe oder Größe setzt, wenn zwei Regeln sich widersprechen. ...

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

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

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

Sie bauen ein Dashboard: Header, Sidebar, Hauptbereich, Footer. Sie greifen zu Flexbox, weil das nun mal das Layout-Werkzeug ist, das Sie kennen – und zwanzig Minuten später stapeln sich drei verschachtelte display: flex-Container, die Sidebar hält ihre Breite nur mit einer willkürlichen Pixelzahl, und der Footer schwebt mitten auf der Seite, sobald der Inhalt kurz ist. Das ist kein Flexbox-Bug. Sie wenden ein eindimensionales Werkzeug auf ein zweidimensionales Problem an. ...

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

Ihr Frontend läuft auf http://localhost:5173, Ihre API auf http://localhost:4000, und der fetch-Aufruf, der in Postman anstandslos funktionierte, schlägt im Browser mit einer Wand aus rotem Text fehl: 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. Ihr Server hat die Anfrage womöglich verarbeitet und eine 200 zurückgegeben. Der Browser hat sich einfach geweigert, die Antwort an Ihr JavaScript weiterzugeben. ...