Web Development

Você escreve .sidebar .card { color: blue; }, carrega a página e o card continua vermelho por causa de uma regra adicionada uma hora antes: .card { color: red; }. A nova regra vem depois no arquivo. Mesmo assim, perde. O navegador compara os dois seletores com um sistema de pontos fixo, e .sidebar .card pontua mais alto que .card, não importa qual você escreveu por último. Esse sistema de pontos é a especificidade. Depois que você aprende a calculá-la de cabeça, “por que meu CSS não se aplica” se torna aritmética pura. Não tem nada a ver com layout: Grid ou Flexbox decide onde um elemento fica, a especificidade decide qual regra define a cor ou o tamanho quando duas regras entram em conflito. ...

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

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

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

Você está montando um dashboard: cabeçalho, barra lateral, área de conteúdo principal, rodapé. Você recorre ao Flexbox porque é a ferramenta de layout que conhece, e vinte minutos depois tem três containers display: flex aninhados, uma barra lateral que não mantém a largura sem um número mágico, e um rodapé que flutua na metade da página quando o conteúdo é curto. Nada disso é um bug do Flexbox. Você está usando uma ferramenta unidimensional para um problema bidimensional. ...

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

Seu frontend roda em http://localhost:5173, sua API em http://localhost:4000, e a chamada fetch que funcionava sem problemas no Postman falha no navegador com uma parede de texto vermelho: 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. Seu servidor pode muito bem ter processado a requisição e retornado um 200. O navegador simplesmente se recusou a entregar a resposta ao seu JavaScript. ...