La lección anterior terminó chocando con un muro: el spread copia solo el primer nivel, así que copia.etiquetas.push('mobiliario') modifica también el original. Y quedó abierta otra pregunta igual de importante: el backlog de Nómada Tareas vive en memoria y desaparece en cuanto se cierra la pestaña; para guardarlo o enviarlo hay que convertirlo en texto. Las dos cuestiones se responden con las mismas herramientas, y ese es el tema de esta lección: JSON como formato de intercambio, con JSON.stringify y JSON.parse y todo lo que se pierde en el viaje de ida y vuelta; y las copias, superficiales y profundas, con structuredClone como respuesta moderna y Object.freeze como red de seguridad. Es la última lección del módulo, así que también cerraremos el círculo: verás qué te falta todavía para que cada tarea deje de repetir los mismos métodos una y otra vez.

1. Qué es JSON
2. JSON no es JavaScript: la tabla de diferencias
3. JSON.stringify: convertir a texto
4. Dar formato con el tercer parámetro
5. Filtrar con el replacer y con el array de claves
6. toJSON: que un objeto decida cómo se serializa
7. Qué se pierde en el viaje de ida y vuelta
8. JSON.parse: volver a convertir en objeto
9. El reviver: transformar mientras se lee
10. JSON.parse siempre dentro de try/catch
11. Copia superficial: { ...obj } y Object.assign
12. Copia profunda: structuredClone y el truco con JSON
13. La tabla de las copias
14. Referencias compartidas: el bug del backlog
15. Object.freeze y su superficialidad
16. Ejemplo integrado: guardar y recuperar el backlog
17. Errores Comunes y Consejos
18. Ejercicios
19. Conclusión

JSON (JavaScript Object Notation) es un formato de texto para representar datos estructurados. Nació de la sintaxis de los objetos de JavaScript, pero hoy es un estándar independiente que entienden prácticamente todos los lenguajes: cuando una aplicación web pide datos a un servidor (Módulo 7), lo que viaja por la red es casi siempre JSON.

Un objeto JavaScript y su representación JSON, lado a lado:

Ese segundo bloque es un string. No tiene propiedades, no se le puede hacer tarea.titulo, no ocupa memoria como objeto: es una secuencia de caracteres que describe un objeto. La diferencia parece obvia y es la fuente del malentendido número uno con JSON.

JSON es texto. Un objeto se «serializa» a JSON para poder guardarlo, enviarlo o compararlo; y se «parsea» de vuelta para volver a trabajar con él.

Los tipos que JSON admite son solo seis: string, number, boolean, null, objeto y array. Nada más.

La sintaxis se parece, pero JSON es mucho más estricto. Estas son las diferencias que provocan errores reales:

Ten presente además que fechaLimite es un string en el modelo de Nómada Tareas. Esa decisión de diseño del Módulo 1, que entonces pudo parecer arbitraria, cobra aquí todo el sentido: como JSON no tiene fechas nativas, guardar '2026-09-05' significa que el dato sobrevive intacto al viaje de ida y vuelta, sin conversiones ni sorpresas.

Funciona con cualquier valor, no solo con objetos:

Esa última línea sorprende: JSON.stringify(undefined) no devuelve 'undefined', devuelve el valor undefined. Es un detalle que puede reventar un localStorage.setItem en el Módulo 7.

El tercer parámetro añade saltos de línea e indentación. Es lo que quieres cuando el JSON lo va a leer una persona:

El null del medio es el segundo parámetro (el replacer, apartado siguiente), que aquí no usamos. El 2 es el número de espacios de indentación; también admite un string, como '\t' para tabuladores.

Truco de depuración muy útil. console.log(objeto) a veces recorta objetos grandes o muestra [Object] en los niveles profundos. console.log(JSON.stringify(objeto, null, 2)) lo muestra entero y legible. Lo usarás constantemente en el Módulo 8.

Para guardar o enviar, en cambio, no formatees: la indentación multiplica el tamaño del texto sin aportar nada a una máquina.

El segundo parámetro decide qué se serializa. Admite dos formas.

Un array de claves, la más sencilla: solo esas propiedades pasan el filtro.

Una función replacer, que se llama para cada par clave-valor y decide qué devolver. Si devuelve undefined, la propiedad se omite.

Dos detalles del replacer: se llama también para la raíz, con la clave '' y el objeto entero como valor; y recuerda que en un array, las claves son los índices como string. Si te olvidas del return valor final, todo se convierte en undefined y el resultado es vacío.

Aplicación real: exportar el backlog sin los campos internos.

Si un objeto tiene un método llamado toJSON, JSON.stringify lo llama y serializa lo que devuelva en lugar del objeto. Es la forma de controlar la representación desde dentro:

Lo mismo hace Date internamente: tiene su propio toJSON que devuelve la fecha en formato ISO, y por eso una fecha se serializa como texto.

Este es el apartado que hay que memorizar. Serializar y volver a parsear no devuelve siempre lo mismo que entró:

La tabla completa:

Los dos últimos merecen atención especial:

Una referencia circular es un objeto que se contiene a sí mismo, directa o indirectamente. Ocurre más de lo que parece: por ejemplo, si a cada subtarea le añades un campo padre que apunta a la tarea que la contiene, el árbol deja de ser serializable con JSON.

Buena noticia para Nómada Tareas: el modelo canónico está compuesto solo de números, strings, null, arrays de strings y objetos anidados. Sobrevive intacto al viaje. Eso no es casualidad: es una consecuencia directa de las decisiones de diseño del Módulo 1.

Y con arrays de objetos, que es como llegará el backlog:

Un punto crucial: JSON.parse produce objetos completamente nuevos. No hay ninguna relación con los objetos originales, aunque el contenido sea idéntico. Es justo esa propiedad la que aprovecharemos para hacer copias profundas.

El segundo parámetro de JSON.parse es una función que se llama para cada par clave-valor al leer, y permite transformar los datos en el momento. El uso clásico es reconstruir fechas:

En Nómada Tareas el reviver sirve para normalizar datos que llegan de fuera, aplicando las reglas de negocio en la puerta de entrada:

Como el replacer, el reviver debe terminar con return valor para todo lo que no transforme; si lo olvidas, el resultado será undefined.

JSON.parse lanza una excepción si el texto no es JSON válido. Y el texto casi siempre viene de fuera: de un servidor, de un fichero, del almacenamiento del navegador. Por tanto, es un candidato perfecto para el try/catch de 02-05.

La versión más completa distingue el error de sintaxis de un contenido válido pero inesperado, usando el class ErrorDeValidacion extends Error que conociste en 02-05:

Fíjate en el orden: primero parsear (que puede fallar por sintaxis), después validar la forma de los datos. Parsear correctamente no garantiza que el contenido sea el que esperas.

Volvamos al muro con el que terminó 04-07. Estas son las dos formas de hacer una copia superficial, y las dos tienen el mismo límite:

Para arrays, las copias superficiales equivalentes son [...array], array.slice() y Array.from(array). Las tres copian la lista, pero si los elementos son objetos, siguen siendo los mismos objetos:

Una copia profunda duplica el objeto y todo lo que contiene, a cualquier profundidad. Hay dos formas prácticas.

structuredClone(valor) es la respuesta moderna: una función global, integrada en el lenguaje y en los navegadores.

Sus virtudes: conserva Date, Map, Set, RegExp y datos binarios, y maneja referencias circulares sin lanzar error. Su límite: no puede clonar funciones; si el objeto tiene un método, lanza un DataCloneError.

El truco con JSON, que verás en muchísimo código anterior a structuredClone:

Funciona, y es simple de recordar, pero arrastra todas las pérdidas del apartado 7: undefined, funciones y símbolos desaparecen; las fechas se convierten en texto; NaN e Infinity se convierten en null; Map y Set se vacían; y una referencia circular lanza TypeError. Además es más lento, porque construye un string intermedio completo.

Cuándo usar cada uno:

• structuredClone por defecto, siempre que tu entorno lo tenga.
• JSON.parse(JSON.stringify(...)) solo si sabes que tus datos son «JSON puro» —justo el caso del backlog canónico de Nómada Tareas— o si trabajas en un entorno antiguo.
• Copia superficial cuando el objeto no tiene niveles anidados, o cuando el anidado es de solo lectura y nadie lo va a mutar.

Y la copia manual, la del apartado 15 de 04-07, que sigue siendo perfectamente válida cuando la estructura es conocida y pequeña:

Fíjate en que solo llega hasta el segundo nivel de subtareas: si mañana Iván añade un tercero, esta copia vuelve a compartir referencias. Ese es exactamente el motivo por el que existen las copias profundas automáticas.

Veamos el problema con un caso realista, el que le ocurriría a Lucía en la aplicación.

El respaldo no servía de nada: [...backlog] creó un array nuevo, pero con los mismos objetos dentro.

La solución, con copia profunda:

Y una regla de decisión para no equivocarte nunca:

Si quieres impedir de verdad que un objeto se modifique, Object.freeze lo congela:

Congelar impide tres cosas: modificar propiedades existentes, añadir nuevas y borrarlas. Es la herramienta correcta para las constantes de configuración del proyecto —PESOS, MARCAS, ESTADOS_VALIDOS—, porque const solo protege la variable, no el contenido (04-01).

Pero Object.freeze es superficial, exactamente igual que el spread:

Para congelar en profundidad hay que recorrer la estructura, y aquí vuelve la recursividad de 03-07:

La comprobación !Object.isFrozen(valor) no es un adorno: evita el bucle infinito si hay referencias circulares. Un consejo de uso: congela las constantes y los datos de configuración, no el estado que la aplicación modifica constantemente; para eso, la disciplina de actualizaciones inmutables de 04-07 es mejor herramienta que la prohibición.

Juntemos todo en la pieza que Nómada Tareas necesitará en el Módulo 7: convertir el backlog en texto para guardarlo, y recuperarlo con garantías.

Ese último bloque revela algo importante: JSON.parse es, de hecho, una copia profunda gratis. El backlog recuperado es completamente independiente del original, y por eso el push no lo contamina.

Tres decisiones de diseño que merece la pena señalar:

1. El documento lleva version. Cuando dentro de un año el modelo cambie, el importador podrá reconocer el formato antiguo y convertirlo, en vez de fallar de forma incomprensible.
2. Se valida después de parsear. JSON válido no significa datos correctos.
3. Se lanza un error con nombre propio, no se devuelve null. Quien llame decide qué hacer, siguiendo el criterio de 02-05.

Guardar ese texto en el navegador es literalmente una línea, localStorage.setItem('nomada-tareas', texto), y es el punto de partida de Almacenamiento Local y de Sesión. Enviarlo a un servidor es otra, con fetch, en 07-02. Aquí ya tienes hecho lo esencial: la conversión y su validación.

1. Confundir el objeto con su JSON. JSON.stringify(tarea).titulo es undefined: un string no tiene propiedades.

2. Llamar a JSON.parse sin try/catch. Cualquier dato corrupto tumba el programa.

3. Parsear dos veces. JSON.parse(JSON.parse(texto)) lanza error salvo casos raros; y si el dato ya es un objeto, JSON.parse(objeto) lo convierte a string primero y suele fallar con Unexpected token o.

4. Esperar que JSON.stringify conserve las funciones. Los métodos de un objeto desaparecen. Al recuperarlo tendrás los datos, pero no el comportamiento.

5. Creer que { ...obj } copia todo. Copia un nivel. Si hay arrays u objetos dentro, se comparten.

6. Usar JSON.parse(JSON.stringify(x)) con Date, Map, Set o undefined. Se pierden o se transforman en silencio. Usa structuredClone.

7. Confiar en Object.freeze para proteger estructuras anidadas. Es superficial; hace falta congelar en profundidad.

8. Formatear el JSON que vas a enviar o guardar. null, 2 es para leer, no para transmitir: multiplica el tamaño sin ninguna ventaja.

Consejo profesional. Trata siempre los datos externos como sospechosos: parsea dentro de un try/catch, valida la forma justo después y no confíes en ningún campo hasta haberlo comprobado. Las tres líneas que cuesta esa disciplina evitan la mayoría de los fallos en producción, y en el Módulo 8 escribirás pruebas precisamente para los casos límite que ahora estás previendo.

Ejercicio 1 — Exportación pública. Escribe exportarPublico(tareas) que devuelva un string JSON formateado con dos espacios, conteniendo solo los campos id, titulo, responsable, estado y fechaLimite de cada tarea. Resuélvelo de dos formas: con el array de claves de JSON.stringify y con una función replacer. Comprueba en ambos casos que el resultado no contiene la palabra revisor.

Ejercicio 2 — El respaldo que sí funciona. Escribe crearRespaldo(backlog) y restaurar(respaldo), de modo que el respaldo sea inmune a cualquier modificación posterior del backlog, incluidas las etiquetas y las subtareas anidadas. Demuestra con console.log que funciona: modifica un título, empuja una etiqueta y cambia una subtarea de segundo nivel, y comprueba que el respaldo sigue intacto. Explica por qué [...backlog] no habría servido.

Ejercicio 3 — Detector de pérdidas. Escribe quePierdeConJSON(objeto) que devuelva un array con los nombres de las propiedades de primer nivel que no sobrevivirían a JSON.parse(JSON.stringify(objeto)), indicando el motivo en el formato 'revisor: undefined desaparece'. Debe detectar undefined, funciones, símbolos, NaN, Infinity, Date, Map y Set. Pruébalo con un objeto que los tenga todos.

Ejercicio 1

La versión con array de claves es mucho más simple y es la que deberías usar. La versión con replacer tiene una trampa que merece comentario: al serializar un array, el replacer se llama con la clave '' para la raíz y con '0', '1', '2'… para cada elemento. Si no dejas pasar esos casos, la función devuelve undefined para todos y el resultado es un JSON vacío. Es el error más frecuente con replacers, y por eso la primera línea del cuerpo comprueba explícitamente la raíz y los índices numéricos.

Ejercicio 2

[...backlog] no habría servido porque solo crea un array nuevo: sus elementos siguen siendo exactamente los mismos objetos que los del backlog original, así que las tres modificaciones se verían también en el respaldo. Es el bug del apartado 14. Fíjate además en que restaurar vuelve a clonar: si devolviera respaldo.tareas directamente, la aplicación empezaría a modificar el propio respaldo y este dejaría de servir para un segundo «deshacer». En este caso concreto, con datos JSON puros, JSON.parse(JSON.stringify(backlog)) habría funcionado igual de bien; structuredClone es preferible porque no depende de que los datos sean serializables.

Ejercicio 3

Tres apuntes técnicos. Number.isFinite(valor) captura de una vez NaN, Infinity y -Infinity, y es preferible a comprobarlos por separado; recuerda de 01-07 que NaN !== NaN, así que compararlo directamente no funcionaría. instanceof comprueba de qué «molde» procede un objeto, y es exactamente el mecanismo que estudiarás en la lección siguiente al ver los prototipos. Y una limitación honesta de esta función: solo revisa el primer nivel; una versión completa tendría que recorrer la estructura recursivamente, con la técnica de 03-07 y la misma precaución con las referencias circulares que aplicaste en congelarProfundo.

Con esta lección cierras el Módulo 4. Sabes que JSON es texto, no un objeto, y conoces la tabla de diferencias que provoca la mayoría de los errores: comillas dobles obligatorias en claves y strings, sin coma final, sin comentarios, sin undefined, sin funciones y sin fechas nativas. Dominas JSON.stringify con sus tres parámetros —el replacer como función o como array de claves, y el null, 2 que lo hace legible—, sabes que un objeto puede decidir su propia representación con toJSON, y tienes memorizado qué se pierde en el viaje: undefined, funciones y símbolos desaparecen; Date se convierte en string; NaN e Infinity en null; Map y Set se vacían; y una referencia circular lanza TypeError. También sabes que JSON.parse admite un reviver para normalizar al vuelo y que nunca debe llamarse sin try/catch, porque el texto siempre viene de fuera.

Y has resuelto el muro que dejó la lección anterior. Una copia superficial —{ ...obj }, Object.assign, [...arr], slice()— duplica un solo nivel y comparte todo lo anidado, lo que convierte un «respaldo» en una ilusión peligrosa. Una copia profunda lo duplica todo: structuredClone como opción por defecto —conserva Date, Map, Set y las referencias circulares, pero no las funciones— y el viejo truco JSON.parse(JSON.stringify(...)) cuando los datos son JSON puro, como es el caso del backlog canónico. Tienes la tabla comparativa, la regla de decisión sobre qué copia necesita cada operación, y Object.freeze para blindar las constantes del proyecto, con la advertencia de que también es superficial y que congelar en profundidad exige recursividad. Por último has escrito exportarBacklog e importarBacklog, con versión de formato, validación tras el parseo y errores con nombre propio: la base de lo que en el Módulo 7 se convertirá en persistencia real.

Mira ahora el módulo entero. Empezaste con seis arrays paralelos y describirTarea pidiendo ocho argumentos. Terminas con un modelo de datos de verdad: cada tarea es un objeto con nueve campos, el backlog es un array de objetos, y sobre él tienes un tablero con métodos y this, el catálogo completo de operaciones de array, las seis formas de iterar con criterio para elegir, el arsenal de find/filter/sort/reduce que produce el informe semanal de Marta, la desestructuración que hace legibles firmas y bucles, el spread que permite actualizar sin destruir, y la serialización que saca los datos de la memoria. Los mismos números de siempre —48 h, 45 abiertas, Iván con 25, la carpintería vencida, esfuerzo 124— pero ahora calculados con dos líneas en lugar de veinte.

Queda, sin embargo, una repetición que no has sabido evitar. Cada vez que quieres que una tarea sepa describirse, validarse o marcarse como hecha, tienes que escribir esos métodos dentro de cada objeto, o mantenerlos como funciones sueltas a las que pasas la tarea. Con seis tareas es incómodo; con seiscientas, cada una arrastraría su propia copia de los mismos métodos, ocupando memoria para hacer exactamente lo mismo. Y ya has visto pistas de que el lenguaje tiene una respuesta: instanceof, que pregunta de qué «molde» procede un objeto; new Tarea(...), aquella tercera forma de invocación que dejamos anotada en 04-02; el class ErrorDeValidacion extends Error que usaste como receta sin entenderla del todo. Todas apuntan a lo mismo: hace falta un molde compartido del que todas las tareas hereden su comportamiento, en lugar de repetirlo objeto a objeto. Ese mecanismo es el corazón de JavaScript y el arranque del Módulo 5: Objetos y Funciones Avanzadas, que empieza con Prototipos y Herencia y continúa con las clases, la encapsulación, los módulos y —el otro gran salto del curso— la asincronía.