JavaScript

Salvi un file, Prettier lo riformatta, ed ESLint segnala subito un errore sulla riga che Prettier ha appena toccato. Entrambi gli strumenti sono configurati, entrambi sono attivi, e invece di aiutarti si combattono a vicenda. I due strumenti fanno lavori diversi. Il problema è che hanno entrambi un’opinione su una cosa sola: come deve apparire il codice sulla pagina. Cosa controlla davvero ESLint ESLint analizza il codice in un albero di sintassi astratto e applica regole sulla sua struttura. Il suo contributo più utile sono le regole che individuano bug reali: una variabile mai definita, un return irraggiungibile dopo un altro return, un import rimasto inutilizzato dopo un refactoring, una chiave duplicata in un oggetto che sovrascrive la prima in silenzio. Sono controlli semantici: ESLint legge cosa fa il codice. ...

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

<.+> contro <b>bold</b> and <i>italic</i> non trova <b>. Trova l’intera stringa, dal primo < all’ultimo >. Non c’è nessun bug. È esattamente quello che un quantificatore greedy deve fare, ed è anche il bug più comune in assoluto quando “il regex matcha troppo”. Una volta capito cosa fa il motore mentre legge il pattern, questo bug e i suoi parenti smettono di essere misteriosi. Come un Motore Regex Legge il Pattern Un motore regex non confronta il pattern con la stringa come si confrontano due stringhe per uguaglianza. I motori che usi ogni giorno (re di Python, RegExp di JavaScript, PCRE, .NET, Java) sono regex-directed: scorrono il pattern da sinistra a destra, token per token, e per ogni token provano a consumare caratteri dalla stringa nella posizione attuale. Quando un token trova corrispondenza, il motore avanza sia il puntatore del pattern che quello della stringa. Quando un token fallisce, il motore fa backtracking: torna all’ultimo punto in cui aveva una scelta, come un quantificatore che poteva fermarsi prima o un ramo di un’alternanza non ancora provato, e prova l’altra opzione. ...

Perché any fa perdere il tipo che hai passato? Tipizza un parametro come any e TypeScript smette di controllare tutto ciò che esce dalla funzione: 1 2 3 4 5 6 function firstElement(arr: any[]): any { return arr[0]; } const n = firstElement([1, 2, 3]); n.toUpperCase(); // compila, va in crash a runtime Tu sai di aver passato un array di numeri. Il compilatore no, perché any gli dice di smettere di guardare. n torna come any, quindi chiamare un metodo di stringa su un numero compila senza problemi e lancia TypeError: n.toUpperCase is not a function quando viene eseguito. ...

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

Lancia npm install su un progetto, poi pnpm install sullo stesso package.json: ottieni due alberi node_modules diversi e due lockfile diversi. Aggiungi un collega che usa Yarn e il repository finisce con tre lockfile nella sua storia, ognuno con un albero delle dipendenze leggermente diverso. Tutti e tre leggono lo stesso package.json e scaricano dal medesimo registro npm. Il punto su cui i tre non sono d’accordo è cosa scrivere su disco. ...

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

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