Web Development

Scrivi .sidebar .card { color: blue; }, carichi la pagina e la card è ancora rossa, per colpa di una regola aggiunta un’ora prima: .card { color: red; }. La nuova regola viene dopo nel file. Perde comunque. Il browser confronta i due selettori con un sistema a punti fisso, e .sidebar .card ottiene un punteggio più alto di .card, indipendentemente da chi è stato scritto per ultimo. Quel sistema a punti è la specificità. Una volta che sai calcolarla a colpo d’occhio, “perché il mio CSS non si applica” diventa aritmetica. Non ha niente a che fare con il layout: Grid o Flexbox decide dove si posiziona un elemento, la specificità decide quale regola ne imposta colore o dimensione quando due regole sono in conflitto. ...

Un componente di chat riconnette il suo WebSocket ogni volta che scrivi una lettera in una casella di ricerca che non ha niente a che fare con la chat. Un altro componente si ri-renderizza in loop finché la tab si blocca. Un terzo registra il suo useEffect due volte al montaggio, ma solo in sviluppo. Nessuno di questi è un bug di React. I primi due sono l’array delle dipendenze che fa esattamente quello che gli hai detto di fare, e il terzo è la Strict Mode che verifica che il tuo effetto sappia pulire dopo di sé. ...

Un listener scroll su window può scattare centinaia di volte durante un singolo swipe. Se ad ogni evento esegui getBoundingClientRect() su tutte le card di un feed, bastano cinquanta immagini per inchiodare la pagina. La Intersection Observer API toglie quel controllo dal percorso dello scroll: registri quali elementi osservare e il browser ti avvisa quando la loro visibilità cambia davvero. Come funziona IntersectionObserver Un observer osserva uno o più elementi target rispetto a un root (di default il viewport) e invoca una callback ogni volta che un target supera una soglia di visibilità. ...

Cos’è una 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 viene eseguita una volta, restituisce una funzione, e la sua chiamata finisce lì: lo stack frame non esiste più. Eppure ogni chiamata a counter() legge e aggiorna count, una variabile dichiarata dentro una funzione già terminata. count non torna a 0, e non viene copiata. È la stessa variabile, ancora viva, tre chiamate dopo. ...

Avvolgi una chiamata fetch() in un try/catch, chiama un endpoint che risponde con un 404, e il blocco catch non si attiva mai. La promise si risolve. res.json() analizza qualunque corpo il server abbia restituito, spesso un payload di errore come {"error": "user not found"}, e il resto della funzione lo tratta come il record che aveva richiesto. Nessuna eccezione, nessun avviso in console. Il dato sbagliato continua a propagarsi finché qualcos’altro non va in errore per colpa sua. ...

Stai costruendo una dashboard: un header, una sidebar, un’area di contenuto principale, un footer. Scegli Flexbox perché è lo strumento di layout che conosci, e venti minuti dopo ti ritrovi con tre container display: flex annidati, una sidebar che non mantiene la sua larghezza senza un numero magico, e un footer che fluttua a metà pagina quando il contenuto è poco. Niente di tutto questo è un bug di Flexbox. Stai usando uno strumento monodimensionale su un problema bidimensionale. ...

Una casella di ricerca che lancia una richiesta a ogni tasto premuto manda cinque richieste per “redis”, e quattro arrivano scadute prima che torni la risposta. Un handler di scroll che ricalcola il layout gira centinaia di volte al secondo e fa scattare la pagina. Stesso problema in entrambi i casi: l’evento del DOM si attiva molto più spesso di quanto serva alla funzione. Debounce e throttle lo risolvono in due modi diversi. ...

Un endpoint di login restituisce un JWT, e hai tre posti dove metterlo: un cookie, localStorage o sessionStorage. Scegli quello sbagliato e succede una di due cose: un bug XSS si porta via il token, oppure il token non arriva mai alla tua API. Tutti e tre salvano stringhe nel browser. Cambiano su chi può leggerle, quanto durano e se il server le vede o no. Che differenza c’è tra localStorage, sessionStorage e cookie localStorage e sessionStorage sono la stessa API, l’interfaccia Storage: setItem, getItem, removeItem, clear, chiavi e valori sempre stringa. La differenza è la durata. localStorage sopravvive alla chiusura del browser e al riavvio della macchina, e resta finché qualcosa non lo svuota. Safari è l’eccezione: con la tracking prevention attiva, elimina lo storage scritto da script per un sito con cui l’utente non ha interagito da sette giorni. sessionStorage appartiene a una singola tab e muore quando quella tab si chiude. Digiti lo stesso URL in una seconda tab e ottieni un sessionStorage nuovo e vuoto; solo “Duplica tab” lo copia. ...

Il frontend gira su http://localhost:5173, l’API su http://localhost:4000, e la fetch che funzionava perfettamente in Postman fallisce nel browser con un muro di testo rosso: 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. Il server potrebbe aver gestito la richiesta e restituito un 200. Il browser ha semplicemente rifiutato di consegnare la risposta al tuo JavaScript. ...