JavaScript

Você salva um arquivo, o Prettier reformata, e o ESLint aponta imediatamente um erro na linha que o Prettier acabou de tocar. As duas ferramentas estão configuradas, as duas estão rodando, e em vez de ajudar, estão brigando uma com a outra. As duas ferramentas fazem trabalhos diferentes. O problema é que as duas têm opinião sobre uma única coisa: a aparência do código na tela. O que o ESLint realmente verifica O ESLint analisa seu código em uma árvore de sintaxe abstrata e executa regras sobre a estrutura dela. A maior parte do seu valor vem de regras que encontram bugs reais: uma variável nunca definida, um return inalcançável depois de outro return, um import que ficou sem uso depois de uma refatoração, uma chave duplicada em um objeto que sobrescreve a primeira em silêncio. São verificações semânticas: o ESLint lê o que o código faz. ...

Um componente de chat reconecta o WebSocket toda vez que você digita uma letra em um campo de busca que não tem nada a ver com o chat. Outro componente re-renderiza em loop até a aba congelar. Um terceiro registra seu useEffect duas vezes ao montar, mas só em desenvolvimento. Nenhum desses é um bug do React. Os dois primeiros são o array de dependências fazendo exatamente o que você pediu, e o terceiro é o Strict Mode verificando se o seu efeito sabe se limpar depois de si mesmo. ...

<.+> contra <b>bold</b> and <i>italic</i> não encontra <b>. Encontra a string inteira, do primeiro < ao último >. Nada está quebrado. É exatamente isso que um quantificador greedy deve fazer, e também é o bug mais comum de “o regex está casando demais”. Depois que você entende o que o motor faz enquanto lê o seu padrão, esse bug e a maioria dos parentes dele deixam de ser mistério. Como um Motor de Regex Lê o Seu Padrão Um motor de regex não compara o seu padrão com a string como você compara duas strings por igualdade. Os motores que você usa no dia a dia (re do Python, RegExp do JavaScript, PCRE, .NET, Java) são regex-directed: eles percorrem o padrão da esquerda para a direita, token por token, e para cada token tentam consumir caracteres da string na posição atual. Quando um token casa, o motor avança tanto o ponteiro do padrão quanto o da string. Quando um token falha, o motor faz backtracking: volta ao último ponto em que tinha uma escolha, como um quantificador que poderia ter casado com menos caracteres ou um ramo de alternância ainda não tentado, e tenta a outra opção. ...

Por Que any Faz Você Perder o Tipo que Passou? Tipe um parâmetro como any e o TypeScript para de verificar tudo o que sai da função: 1 2 3 4 5 6 function firstElement(arr: any[]): any { return arr[0]; } const n = firstElement([1, 2, 3]); n.toUpperCase(); // compila, quebra em tempo de execução Você sabe que passou um array de números. O compilador não sabe, porque any faz ele parar de olhar. O tipo de n fica any, então chamar um método de string em um número compila sem problemas e lança TypeError: n.toUpperCase is not a function em tempo de execução. ...

Um listener de scroll em window pode disparar centenas de vezes durante um único swipe. Se você executa getBoundingClientRect() em cada card de um feed a cada um desses eventos, cinquenta imagens já bastam para a página engasgar. A Intersection Observer API tira essa verificação do caminho do scroll: você registra quais elementos observar, e o navegador avisa quando a visibilidade deles muda de fato. Como o IntersectionObserver funciona Um observer vigia um ou mais elementos target em relação a um root (o viewport, por padrão) e chama um callback sempre que um target cruza um limite de visibilidade. ...

O Que É uma Closure em 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 executa uma vez, retorna uma função, e aí termina: seu stack frame não existe mais. Ainda assim, cada chamada a counter() continua lendo e atualizando count, uma variável declarada dentro de uma função que já terminou. count não volta para 0, e não é copiada. É a mesma variável, ainda viva, três chamadas depois. ...

Rode npm install em um projeto, depois pnpm install sobre o mesmo package.json, e você tem duas árvores node_modules diferentes e dois lockfiles diferentes. Acrescente um colega que usa Yarn e o repositório acaba com três lockfiles no histórico, cada um descrevendo uma árvore de dependências ligeiramente diferente. Os três leem o mesmo package.json e baixam do mesmo registro do npm. O que eles não combinam entre si é o que gravar no disco. ...

Envolva uma chamada fetch() em um try/catch, acerte um endpoint que responde com 404, e o bloco catch nunca executa. A promise se resolve. res.json() analisa qualquer corpo que o servidor tenha devolvido, muitas vezes um payload de erro como {"error": "user not found"}, e o resto da função trata isso como o registro que pediu. Nenhuma exceção, nenhum aviso no console. O dado errado segue adiante até algo mais quebrar por causa dele. ...

Um campo de busca que dispara uma requisição a cada tecla envia cinco requisições para “redis”, e quatro chegam desatualizadas antes de a resposta voltar. Um handler de scroll que recalcula o layout roda centenas de vezes por segundo e deixa a página travando. O mesmo problema nos dois casos: o evento do DOM dispara muito mais vezes do que o handler precisa rodar. Debounce e throttle resolvem isso de duas formas diferentes. ...

Um endpoint de login devolve um JWT, e você tem três lugares para colocá-lo: um cookie, localStorage ou sessionStorage. Escolha errado, e ou um bug de XSS leva o token embora, ou o token nunca chega à sua API. Os três guardam strings no navegador. Eles diferem em quem pode lê-los, quanto tempo duram, e se o servidor chega a vê-los. Como localStorage, sessionStorage e cookies se diferenciam localStorage e sessionStorage são a mesma API, a interface Storage: setItem, getItem, removeItem, clear, chaves e valores em string. A diferença é o tempo de vida. localStorage sobrevive ao fechar o navegador e reiniciar a máquina, e permanece até algo limpá-lo. O Safari é a exceção: com a prevenção de rastreamento ativada, ele apaga o storage escrito por script de um site com o qual o usuário não interage há sete dias. sessionStorage pertence a uma aba e morre quando essa aba fecha. Digite a mesma URL em uma segunda aba e você recebe um sessionStorage novo e vazio; só “Duplicar aba” copia o conteúdo. ...