Web Development

Escribes .sidebar .card { color: blue; }, cargas la página y la tarjeta sigue en rojo por una regla que añadiste una hora antes: .card { color: red; }. Tu nueva regla va después en el archivo. Sigue perdiendo. El navegador compara los dos selectores con un sistema de puntos fijo, y .sidebar .card puntúa más alto que .card sin importar cuál escribiste al final. Ese sistema de puntos es la especificidad. En cuanto sabes calcularla a simple vista, “por qué no se aplica mi CSS” se vuelve aritmética. No tiene nada que ver con el layout: Grid o Flexbox decide dónde se coloca un elemento, y la especificidad decide qué regla fija su color o tamaño cuando dos reglas entran en conflicto. ...

Un componente de chat reconecta su WebSocket cada vez que escribes una letra en un buscador que no tiene nada que ver con el chat. Otro componente se re-renderiza en bucle hasta que la pestaña se congela. Un tercero registra su useEffect dos veces al montarse, pero solo en desarrollo. Ninguno de estos es un bug de React. Los dos primeros son el array de dependencias haciendo exactamente lo que le pediste, y el tercero es Strict Mode comprobando que tu efecto sabe limpiar después de sí mismo. ...

Un listener scroll en window puede dispararse cientos de veces durante un solo swipe. Si en cada uno de esos eventos ejecutas getBoundingClientRect() sobre todas las tarjetas de un feed, cincuenta imágenes bastan para que la página empiece a ir a tirones. La Intersection Observer API elimina esa comprobación del flujo del scroll: registras qué elementos observar y el navegador te avisa cuando su visibilidad cambia de verdad. Cómo funciona IntersectionObserver Un observer vigila uno o más elementos target respecto a un root (el viewport, por defecto) y llama a una callback cada vez que un target cruza un umbral de visibilidad. ...

¿Qué Es una Closure en 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 se ejecuta una vez, devuelve una función, y ahí termina: su stack frame ya no existe. Aun así, cada llamada a counter() sigue leyendo y actualizando count, una variable declarada dentro de una función que ya terminó. count no vuelve a 0, y no se copia. Es la misma variable, todavía viva, tres llamadas después. ...

Envuelve una llamada fetch() en un try/catch, apunta a un endpoint que responde con un 404, y el bloque catch nunca se ejecuta. La promesa se resuelve. res.json() analiza el cuerpo que haya devuelto el servidor, muchas veces un payload de error como {"error": "user not found"}, y el resto de la función lo trata como el registro que pedía. Sin excepción, sin aviso en consola. El dato incorrecto sigue viajando hasta que algo más se rompe con él. ...

Estás montando un dashboard: un header, un sidebar, un área de contenido principal y un footer. Recurres a Flexbox porque es la herramienta de layout que conoces, y veinte minutos después tienes tres contenedores display: flex anidados, un sidebar que no mantiene su ancho sin un número mágico, y un footer que flota a mitad de página cuando el contenido es corto. Nada de eso es un bug de Flexbox. Estás usando una herramienta unidimensional para un problema bidimensional. ...

Un buscador que lanza una petición en cada pulsación manda cinco peticiones para “redis”, y cuatro llegan obsoletas antes de que vuelva la respuesta. Un handler de scroll que recalcula el layout se ejecuta cientos de veces por segundo y hace que la página se trabe. El mismo problema en los dos casos: el evento del DOM se dispara mucho más a menudo de lo que el handler necesita ejecutarse. Debounce y throttle lo resuelven de dos formas distintas. ...

Un endpoint de login te devuelve un JWT, y tienes tres lugares donde guardarlo: una cookie, localStorage o sessionStorage. Si eliges mal, un bug de XSS se lleva el token, o el token nunca llega a tu API. Las tres opciones guardan strings en el navegador. Se diferencian en quién puede leerlas, cuánto duran y si el servidor llega a verlas. En qué se diferencian localStorage, sessionStorage y las cookies localStorage y sessionStorage son la misma API, la interfaz Storage: setItem, getItem, removeItem, clear, claves string y valores string. La diferencia está en la duración. localStorage sobrevive a cerrar el navegador y reiniciar la máquina, y se queda hasta que algo lo borra. Safari es la excepción: con la prevención de rastreo activada, borra el almacenamiento escrito por script de un sitio con el que el usuario no ha interactuado en siete días. sessionStorage pertenece a una pestaña y muere cuando esa pestaña se cierra. Si escribes la misma URL en una segunda pestaña obtienes un sessionStorage nuevo y vacío; solo “Duplicar pestaña” lo copia. ...

Tu frontend corre en http://localhost:5173, tu API en http://localhost:4000, y la llamada fetch que funcionaba sin problemas en Postman falla en el navegador con una pared de texto rojo: 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. Es muy probable que tu servidor haya procesado esa petición y devuelto un 200. El navegador se negó a entregar la respuesta a tu JavaScript. ...