Referencias vs copias: el bug más desconcertante

Modificas la "copia" de un objeto... y el original también cambia. Este bug desconcierta a todo principiante (y a más de un senior), y la causa es una sola idea que hoy vas a fijar para siempre: las variables NO guardan objetos — guardan la dirección donde vive el objeto.

La dirección de la casa

El bug del alias

Los tipos primitivos (números, strings, booleanos) se copian por VALOR: cada variable tiene el suyo. Los objetos y arrays se copian por REFERENCIA: la variable guarda la dirección. Consecuencia directa: === entre objetos compara direcciones, no contenidos — solo da true si es exactamente el mismo objeto.

Copia superficial: hasta el primer nivel

El spread SÍ construye un objeto nuevo... pero solo copia el primer nivel. Si adentro había otro objeto, lo que se copia es SU referencia.

Copia profunda: structuredClone

structuredClone construye la casa Y la casita del patio: clona todos los niveles, sin compartir nada.

Nota honesta: structuredClone clona datos (objetos, arrays, fechas, Map, Set...) pero NO funciones — un objeto con métodos no se puede clonar así. Y no lo uses "por si acaso" en todo: para el caso común de un objeto plano, el spread basta y es más barato. Regla práctica: spread por defecto; structuredClone cuando hay anidación que vas a modificar.

Mini-reto

Reproduce el bug y arréglalo: crea un gasto con un objeto anidado detalle: { propina: 2000 }. Haz una copia con spread, cambia la propina de la copia y comprueba que el original se dañó. Luego repite con structuredClone y comprueba que quedó protegido. Ver el bug con tus propios ojos vale más que releer esta lección tres veces.

Qué sigue

Ya dominas cómo viven los objetos en memoria. El siguiente dolor real: objetos anidados donde algo puede NO existir — titular.direccion.ciudad explota si direccion falta. La próxima lección trae el optional chaining (?.) y el nullish coalescing (??): navegar estructuras con huecos sin que nada explote.