Web Development

Piszesz .sidebar .card { color: blue; }, ładujesz stronę, a karta jest wciąż czerwona przez regułę dodaną godzinę wcześniej: .card { color: red; }. Nowa reguła jest niżej w pliku. I mimo to przegrywa. Przeglądarka porównuje dwa selektory przy użyciu stałego systemu punktowego, a .sidebar .card dostaje wyższy wynik niż .card, niezależnie od tego, który napisano później. Ten system punktowy to specyficzność. Kiedy już umiesz ją liczyć od razu, “czemu mój CSS się nie stosuje” staje się arytmetyką. Nie ma to nic wspólnego z layoutem: Grid czy Flexbox decyduje, gdzie znajduje się element, a specyficzność decyduje, która reguła ustawia jego kolor albo rozmiar, gdy dwie reguły są w konflikcie. ...

Komponent czatu łączy się ponownie przez WebSocket za każdym razem, gdy wpisujesz literę w polu wyszukiwania, które nie ma nic wspólnego z czatem. Inny komponent renderuje się w kółko, aż karta się zawiesza. Trzeci wywołuje swój useEffect dwa razy przy montowaniu, ale tylko w trybie deweloperskim. Żaden z tych przypadków nie jest błędem Reacta. Dwa pierwsze to tablica zależności robiąca dokładnie to, co jej kazano, a trzeci to Strict Mode sprawdzający, czy twój efekt umie się po sobie posprzątać. ...

Listener scroll na window może odpalać się setki razy podczas jednego przesunięcia ekranu. Jeśli przy każdym takim evencie wywołujesz getBoundingClientRect() na każdej karcie w feedzie, pięćdziesiąt obrazów wystarczy, żeby strona zaczęła się zacinać. Intersection Observer API zdejmuje to sprawdzenie ze ścieżki scrolla: rejestrujesz, jakie elementy obserwować, a przeglądarka informuje cię, gdy ich widoczność naprawdę się zmienia. Jak działa IntersectionObserver Observer obserwuje jeden lub więcej elementów target względem root (domyślnie viewport) i wywołuje callback, gdy target przekroczy próg widoczności. ...

Co to jest closure w 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 działa raz, zwraca funkcję i na tym koniec: jej stack frame już nie istnieje. Mimo to każde wywołanie counter() wciąż odczytuje i aktualizuje count — zmienną zadeklarowaną wewnątrz funkcji, która już się zakończyła. count nie wraca do 0 i nie jest kopiowana. To wciąż ta sama zmienna, żywa, trzy wywołania później. ...

Owiń wywołanie fetch() w try/catch, trafiasz na endpoint, który odpowiada 404, a blok catch nigdy się nie uruchamia. Promise się rozwiązuje. res.json() parsuje to, co serwer odesłał, często payload błędu w stylu {"error": "user not found"}, a reszta funkcji traktuje to jak żądany rekord. Żadnego wyjątku, żadnego ostrzeżenia w konsoli. Złe dane płyną dalej, aż coś inne się na nich wywala. 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; // przy 404 to jest { error: "user not found" } } catch (err) { console.error('Failed to load user:', err); } } Ten catch odpala się tylko dla żądania, które nigdy się nie kończy. Wszystko inne wymaga sprawdzenia, które musisz napisać samodzielnie. ...

Budujesz dashboard: header, sidebar, główna treść, footer. Sięgasz po Flexbox, bo to narzędzie layoutowe, które znasz, a dwadzieścia minut później masz trzy zagnieżdżone kontenery display: flex, sidebar, który nie utrzyma swojej szerokości bez magicznej liczby, i footer, który unosi się w połowie strony, gdy treści jest mało. To nie jest błąd Flexbox — to Ty używasz narzędzia jednowymiarowego do problemu dwuwymiarowego. Flexbox rozkłada przestrzeń wzdłuż jednej linii: wiersza albo kolumny. Grid ustawia elementy w wierszach i kolumnach naraz, a te wiersze i kolumny odnoszą się do siebie. Większość zamieszania wokół Grid kontra Flexbox wynika z przeskoczenia tej różnicy. ...

Pole wyszukiwania, które wysyła zapytanie przy każdym naciśnięciu klawisza, wysyła pięć zapytań dla “redis”, a cztery z nich są już nieaktualne, zanim wróci odpowiedź. Handler scroll, który przelicza layout, odpala się setki razy na sekundę i powoduje szarpanie strony. W obu przypadkach ten sam problem: zdarzenie DOM odpala się dużo częściej, niż handler musi się wykonać. Debounce i throttle rozwiązują to na dwa różne sposoby. Co robi debounce, a co robi throttle Debounce czeka, aż zdarzenie przestanie się odpalać na ustalony czas, i wtedy wykonuje się raz. Każde nowe wywołanie resetuje zegar. Jeśli zdarzenie nigdy się nie zatrzymuje, funkcja nigdy się nie wykonuje. Pole wyszukiwania to typowy przypadek: czekaj, aż użytkownik zrobi przerwę w pisaniu, a potem wyślij zapytanie z tym, co wpisał na końcu. ...

Endpoint logowania odsyła JWT, a Ty masz trzy miejsca, w których możesz go trzymać: cookie, localStorage albo sessionStorage. Wybierzesz źle i albo błąd XSS wyniesie token na zewnątrz, albo token nigdy nie dotrze do Twojego API. Wszystkie trzy mechanizmy przechowują stringi w przeglądarce. Różnią się tym, kto może je odczytać, jak długo żyją i czy serwer w ogóle je widzi. Czym różnią się localStorage, sessionStorage i cookies localStorage i sessionStorage to ten sam interfejs, Storage: setItem, getItem, removeItem, clear, klucze i wartości w postaci stringów. Różnica leży w czasie życia. localStorage przetrwa zamknięcie przeglądarki i restart komputera, i zostaje tam, dopóki coś go nie wyczyści. Safari jest wyjątkiem: z włączonym tracking prevention usuwa dane zapisane przez skrypt dla strony, z którą użytkownik nie miał kontaktu od siedmiu dni. sessionStorage należy do jednej karty i umiera, gdy ta karta się zamyka. Wpisz ten sam adres w drugiej karcie i dostaniesz nowy, pusty sessionStorage — tylko opcja “Duplikuj kartę” kopiuje go dalej. ...

Twój frontend działa na http://localhost:5173, API na http://localhost:4000, a zapytanie fetch, które bez problemu działało w Postmanie, w przeglądarce kończy się ścianą czerwonego tekstu: 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. Całkiem możliwe, że twój serwer obsłużył to zapytanie i zwrócił 200. Przeglądarka po prostu odmówiła przekazania odpowiedzi do twojego JavaScriptu. Ta odmowa to same-origin policy. CORS to sposób, w jaki serwer mówi przeglądarce, żeby złagodziła tę zasadę dla konkretnych stron. Każda poprawka poniżej sprowadza się do jednego nagłówka odpowiedzi, którego przeglądarka nie dostała. ...