JavaScript

Guardas un archivo, Prettier lo reformatea, y ESLint marca de inmediato un error en la línea que Prettier acaba de tocar. Las dos herramientas están configuradas, las dos están activas, y en vez de ayudarte se pelean entre sí. Las dos herramientas hacen trabajos distintos. El problema es que ambas tienen una opinión sobre una sola cosa: cómo debe verse el código en la pantalla. Qué comprueba realmente ESLint ESLint analiza tu código en un árbol de sintaxis abstracta y ejecuta reglas sobre su estructura. La mayor parte de su valor viene de reglas que detectan bugs reales: una variable que nunca se define, un return inalcanzable después de otro return, un import que quedó sin usar tras una refactorización, una clave duplicada en un objeto que sobrescribe la primera en silencio. Son comprobaciones semánticas: ESLint lee lo que el código hace. ...

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

<.+> contra <b>bold</b> and <i>italic</i> no encuentra <b>. Encuentra toda la cadena, desde el primer < hasta el último >. No hay ningún error. Eso es justo lo que debe hacer un cuantificador greedy, y también es el bug más común de “el regex está matcheando de más”. Una vez que sabes qué hace el motor mientras lee tu patrón, este bug y la mayoría de sus parientes dejan de ser un misterio. ...

¿Por Qué any Hace que Pierdas el Tipo que Pasaste? Tipa un parámetro como any y TypeScript deja de comprobar todo lo que sale de la función: 1 2 3 4 5 6 function firstElement(arr: any[]): any { return arr[0]; } const n = firstElement([1, 2, 3]); n.toUpperCase(); // compila, falla en tiempo de ejecución Tú sabes que pasaste un array de números. El compilador no, porque any le dice que deje de mirar. n queda tipado como any, así que llamar a un método de string sobre un número compila sin problemas y lanza TypeError: n.toUpperCase is not a function cuando se ejecuta. ...

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

Ejecuta npm install en un proyecto, luego pnpm install sobre el mismo package.json, y obtienes dos árboles node_modules distintos y dos lockfiles distintos. Añade un compañero que usa Yarn y el repositorio termina con tres lockfiles en su historial, cada uno describiendo un árbol de dependencias ligeramente diferente. Los tres leen el mismo package.json y descargan del mismo registro de npm. En lo que no se ponen de acuerdo es en qué escribir en disco. ...

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

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