Prometimos que el alivio llegaría en la primera página, así que empecemos por ahí. Durante todo el Módulo 3 has arrastrado seis arrays paralelos —titulos[i], responsables[i], prioridades[i], estados[i], horas[i], fechasLimite[i]— y una función, describirTarea, que necesitaba ocho argumentos para pintar una sola línea. Cada vez que querías filtrar, filtrabas índices en lugar de tareas. Cada vez que añadías un campo al modelo, tocabas todas las funciones. En esta lección eso se acaba: aprenderás qué es un objeto en JavaScript, cómo se crea, cómo se leen y modifican sus propiedades, y usarás ese conocimiento para escribir por fin el backlog real de Nómada Tareas como un array de objetos, con la firma limpia describirTarea(tarea, hoy). Es el cambio más importante del curso hasta ahora, porque a partir de aquí el código deja de simular el modelo de datos y pasa a contenerlo.

1. El problema: seis arrays que hay que mantener alineados
2. Qué es un objeto: literales, propiedades y valores
3. Acceso con punto y acceso con corchetes
4. Añadir, modificar y borrar propiedades
5. Propiedades que no existen: undefined y el encadenamiento opcional
6. Comprobar si una propiedad existe
7. El backlog real: un array de objetos
8. La recompensa: describirTarea(tarea, hoy)
9. Objetos anidados: la tarea con sus subtareas
10. Nombres de propiedad computados
11. Recorrer un objeto: for...in y Object.keys/values/entries
12. Objetos como diccionario de consulta
13. Una mención breve a Map y Set
14. Errores Comunes y Consejos
15. Ejercicios
16. Conclusión

Antes de celebrar la solución, mira el problema con toda su crudeza. Así estaba el backlog al final del Módulo 3:

Este diseño tiene tres defectos graves, y conviene nombrarlos:

Un objeto resuelve los tres de una vez: agrupa datos relacionados bajo un mismo valor, con nombres en lugar de posiciones.

Un objeto es una colección de pares clave → valor. La forma de crearlo es el literal de objeto: llaves {} con las parejas dentro.

Vocabulario preciso, porque lo usarás en todo el módulo:

• Propiedad: cada pareja completa, por ejemplo titulo: 'Rediseñar la sala polivalente'.
• Clave (o nombre de propiedad): la parte izquierda, titulo. Siempre es un string internamente (o un Symbol, que no veremos aquí). Aunque escribas { 1: 'uno' }, la clave real es '1'.
• Valor: la parte derecha. Puede ser cualquier cosa: un número, un string, null, un array (etiquetas), otro objeto, o incluso una función (eso son los métodos, y llegan en la lección siguiente).

Tres detalles de sintaxis que ahorran disgustos:

Las claves no llevan comillas si son identificadores válidos de JavaScript (letras, dígitos que no van al principio, _ y $). Si la clave tiene un guion, un espacio o un acento problemático, hay que entrecomillarla. En Nómada Tareas usamos siempre claves en camelCase sin comillas: horasEstimadas, fechaLimite.

Y recuerda lo que ya sabes de 01-05: typeof de un objeto es 'object', y los objetos son valores de referencia. Dos objetos con el mismo contenido no son iguales:

Hay dos formas de leer una propiedad, y no son intercambiables.

Esa última línea es el error clásico: tarea.campo busca una propiedad llamada campo, no el contenido de la variable campo. Cuándo hace falta cada notación:

Un caso práctico donde los corchetes son imprescindibles: una función genérica que ordena o compara por el campo que le digas.

Los objetos declarados con const sí se pueden modificar. Lo que const impide es reasignar la variable, no cambiar el contenido del objeto al que apunta (esto lo viste en 01-05 con primitivos frente a referencias).

Sobre delete, dos matices importantes:

• delete no es lo mismo que poner undefined. Tras delete tarea.revisor, la clave revisor ya no existe en el objeto. Tras tarea.revisor = undefined, la clave existe y su valor es undefined. Leyendo con el punto no notas la diferencia, pero 'revisor' in tarea sí (apartado 6), y también la notan Object.keys y JSON.stringify (lección 04-08).
• En Nómada Tareas casi nunca usamos delete. El modelo dice que revisor es «string o null»: un revisor ausente se representa con null, que es un valor explícito, no borrando la clave. Borrar campos del modelo canónico rompe las funciones que esperan encontrarlos.

Leer una propiedad inexistente no da error: devuelve undefined.

Esa segunda línea explica por qué las erratas en nombres de propiedad son tan traicioneras: JavaScript no te avisa, simplemente te da undefined y el fallo aparece tres funciones más allá. (En 08-02 verás cómo un linter y las anotaciones de tipo detectan esto antes de ejecutar.)

Lo que sí revienta es intentar leer una propiedad de undefined:

Aquí es donde vuelve el encadenamiento opcional ?. que conociste en 01-06. Si lo que hay a la izquierda es null o undefined, la expresión entera se detiene y devuelve undefined en lugar de lanzar el error:

Combinado con ?? (fusión de nulos), tienes la pareja perfecta para leer datos que puede que no estén: ?. evita el error y ?? pone el valor por defecto. Un ejemplo directo del proyecto, donde revisor puede ser null:

Cuidado con abusar de ?.. Si escribes tarea?.titulo?.length en todas partes, estás tapando el hecho de que no sabes qué datos recibes. Úsalo donde el dato es legítimamente opcional (revisor, un campo que aún no existe), no como red de seguridad universal.

Hay cuatro maneras de preguntar «¿tiene este objeto esta propiedad?», y no responden exactamente a la misma pregunta.

¿Cuál usar? La regla práctica:

• Object.hasOwn(obj, clave) cuando quieres saber si la clave está presente. Es la forma moderna y la que deberías escribir por defecto.
• obj.clave !== undefined (o directamente if (obj.clave), con cuidado con los falsy de 01-07) cuando lo que te importa es el valor.
• in funciona, pero también encuentra propiedades heredadas del prototipo (Módulo 5), lo que a veces sorprende.
• hasOwnProperty es el veterano; Object.hasOwn existe precisamente para sustituirlo con menos trampas.

Ejemplo real: validar que un objeto recibido tiene todos los campos obligatorios del modelo.

Fíjate en que revisor no está en la lista: es opcional, y su ausencia se representa con null.

Ha llegado el momento. Este bloque de código es la fuente de verdad del resto del módulo; lo vas a ver reaparecer en las siete lecciones siguientes.

Los datos son exactamente los mismos de siempre —48 h totales, 45 h abiertas, Iván con tres tareas y 25 h, «Presupuesto de la carpintería» vencida— pero ahora cada tarea es una unidad. Compruébalo:

Lee despacio backlog[2].etiquetas[0]: del array backlog coge el elemento en la posición 2 (un objeto), de ese objeto lee la propiedad etiquetas (un array) y de ese array coge el elemento 0 (un string). El acceso se encadena de izquierda a derecha, paso a paso.

Y ahora la comprobación que importa: borrar una tarea ya no puede desalinear nada.

Recuperemos las funciones del Módulo 3 y reescribámoslas con el modelo real.

Compara las dos firmas de describirTarea:

Este es el beneficio real de los objetos: los datos que van juntos viajan juntos. Y fíjate en el efecto colateral en estaVencida(tarea, hoy): pasó de tres parámetros a dos, y ya no puede recibir la fecha de una tarea con el estado de otra.

En 03-07 usaste, a regañadientes, un objeto con subtareas anidadas. Ahora ya puedes leerlo con propiedad:

La última línea muestra por qué ?. es tan útil con estructuras anidadas: subtareas[9] no existe, y sin ?. obtendrías un TypeError. Un valor puede anidarse tan profundo como quieras: un objeto dentro de un array dentro de un objeto dentro de un array. El acceso siempre se lee de izquierda a derecha, un paso cada vez.

A veces la clave de una propiedad no se conoce hasta que el programa corre. La sintaxis de nombre de propiedad computado permite calcularla dentro del propio literal, poniéndola entre corchetes:

Se puede usar cualquier expresión que produzca un string:

Un uso práctico: una función que construye un criterio de búsqueda a partir del campo que el usuario elija en el futuro panel de Nómada Tareas.

Un array se recorre por posiciones; un objeto se recorre por claves. Hay dos caminos.

for...in recorre las claves (siempre como strings):

Fíjate en el acceso: dentro del bucle hay que usar corchetes, tarea[clave], porque la clave está en una variable. tarea.clave daría undefined nueve veces.

Los tres métodos de Object convierten el objeto en arrays, que ya sabes manejar:

Comparación práctica:

En la práctica, Object.entries con un for...of es la opción por defecto, y for...in queda para casos puntuales:

En 04-06 verás cómo escribir eso mismo como for (const [clave, valor] of Object.entries(tarea)), que es mucho más legible.

Un ejemplo útil: contar cuántos campos del modelo están vacíos.

Hay un segundo uso de los objetos, distinto de «agrupar los campos de una entidad»: usarlos como diccionario o tabla de consulta, donde las claves son datos y no nombres fijos. Ya lo viste de pasada en 02-03 como alternativa al switch:

Compara las dos versiones de la misma función:

El patrón se generaliza a cualquier traducción valor → valor:

Observa que 'en-curso' necesita comillas como clave, porque el guion no es válido en un identificador. Al leerla, MARCAS['en-curso'] con corchetes; MARCAS.en-curso sería un error de sintaxis (JavaScript lo leería como una resta).

Y un tercer uso, el índice por identificador, que evita recorrer el backlog entero cada vez que buscas una tarea:

En 04-05 construirás este índice de forma mucho más elegante con reduce.

Los objetos como diccionario tienen dos límites: sus claves solo pueden ser strings (todo lo demás se convierte a string) y no llevan la cuenta de cuántas entradas tienen. Para esos casos JavaScript ofrece dos estructuras dedicadas:

• Map: un diccionario donde la clave puede ser cualquier valor (un número de verdad, un objeto, una función), conserva el orden de inserción y tiene .size.
• Set: una colección de valores sin duplicados, ideal para deduplicar etiquetas.

No las desarrollamos aquí: aparecen con detalle en Buscar, Ordenar y Agregar Datos, cuando tengas que agrupar y deduplicar de verdad. Para el 95 % de lo que harás en este curso, un objeto literal es suficiente.

1. Usar el punto cuando la clave está en una variable.

2. Olvidar las comillas al leer una clave con corchetes.

Con corchetes, lo de dentro es una expresión. Sin comillas, JavaScript busca una variable con ese nombre.

3. Creer que const congela el objeto. No lo hace: const protege la variable, no el contenido. Para impedir cambios en el objeto existe Object.freeze, que verás en 04-08.

4. Confundir «no existe» con «vale undefined». Usa Object.hasOwn cuando la pregunta sea sobre la clave; compara con undefined cuando sea sobre el valor.

5. Encadenar accesos sin protección. tarea.subtareas[0].titulo explota si subtareas está vacío. Con tarea.subtareas[0]?.titulo obtienes undefined y sigues vivo.

6. Poner una coma de más entre propiedades. { id: 1,, titulo: 'x' } es un error de sintaxis. La coma final ({ id: 1, }) sí está permitida y es buena práctica: los diffs de Git salen más limpios.

Consejo profesional. Elige un orden fijo para los campos —en Nómada Tareas: id, titulo, responsable, prioridad, estado, etiquetas, horasEstimadas, fechaLimite, revisor— y respétalo en todos los objetos. Leer código es comparar, y comparar es mucho más rápido cuando todo está en el mismo sitio.

Ejercicio 1 — Fichas del taller. Crea un objeto taller que describa el espacio de Taller Nómada con las propiedades nombre ('Taller Nómada'), plazas (18), zonas (array con 'coworking', 'serigrafía', 'encuadernación', 'carpintería') y coordinadora ('Marta'). Después:

1. Muestra por consola la segunda zona.
2. Añade la propiedad abiertoSabados con valor true.
3. Cambia plazas a 20.
4. Borra coordinadora y comprueba con Object.hasOwn que ya no está.
5. Lee una propiedad inexistente telefono sin que el programa falle, mostrando 'sin teléfono' si no existe.

Ejercicio 2 — Diccionario de plazos. Escribe una función diasDeMargen(prioridad) que, usando un objeto de consulta (no if ni switch), devuelva cuántos días de margen tiene una tarea según su prioridad: alta → 3, media → 7, baja → 15. Si la prioridad es desconocida, debe devolver 30. Prueba con 'alta', 'baja' y 'ninguna'.

Ejercicio 3 — Inspector de tareas. Escribe una función inspeccionar(tarea) que reciba una tarea del backlog y devuelva un string multilínea con una línea por campo, en el formato clave: valor, saltándose el campo etiquetas. Después escribe resumenDeCampos(tarea), que devuelva un objeto con tres propiedades: total (número de campos), vacios (número de campos cuyo valor sea null) y nombres (array con los nombres de los campos). Pruébalo con backlog[1].

Ejercicio 1

El error frecuente aquí es el punto 1: taller.zonas[2] devolvería 'encuadernación', la tercera. Recuerda que la posición 1 es el segundo elemento.

Ejercicio 2

Detalle importante: aquí ?? es más correcto que ||. Si algún día una prioridad tuviera margen 0, MARGEN_EN_DIAS[p] || 30 devolvería 30 porque 0 es falsy, mientras que ?? solo actúa ante null o undefined. Es exactamente la distinción que estudiaste en 01-06.

Ejercicio 3

Dos observaciones. Primera: resumenDeCampos devuelve un objeto, que es justo lo que recomendaba 03-03 para retornar varios valores con nombre; ahora ya sabes cómo se construye ese objeto. Segunda: el continue dentro del for...of es el mismo de 02-04, y aquí sirve para saltarse el campo etiquetas sin romper el bucle.

Has saldado la deuda. Un objeto es una colección de pares clave → valor que se escribe con un literal {}; sus propiedades se leen con punto cuando conoces el nombre y con corchetes cuando el nombre está en una variable o se calcula. Sabes añadir y modificar propiedades sobre la marcha, borrarlas con delete (y por qué en este proyecto casi nunca conviene), y qué ocurre al leer una que no existe: undefined, sin error, salvo que intentes seguir encadenando —para eso está ?., que ahora entiendes de verdad—. Tienes también la tabla de las cuatro formas de comprobar la existencia de una clave, con Object.hasOwn como opción recomendada.

Y sobre todo tienes el backlog real: seis objetos dentro de un array, con los mismos datos de siempre (48 h totales, 45 abiertas, Iván con 25 h, la carpintería vencida) pero por fin estructurados. Con él has reescrito estaVencida(tarea, hoy) y describirTarea(tarea, hoy), y has comprobado el cambio de escala: de ocho parámetros posicionales a dos, de seis arrays que había que mantener sincronizados a una lista que se borra y se ordena sin miedo. Has visto además los objetos anidados del árbol de subtareas, los nombres de propiedad computados { [clave]: valor }, las cuatro formas de recorrer un objeto (for...in, Object.keys, Object.values, Object.entries) y el uso de los objetos como diccionario de consulta, que convierte cuatro if en una línea.

Pero un objeto puede contener algo más que datos. Si PESOS puede vivir dentro de un objeto, ¿por qué no pesoDePrioridad? ¿Y si el tablero de Taller Nómada guardara, junto a su lista de tareas, las propias operaciones de agregar una tarea o cambiarle el estado? Eso es exactamente lo que veremos en Métodos de Objeto y la Palabra Clave this: funciones guardadas en propiedades, la sintaxis abreviada para escribirlas y esa palabra clave, this, que es a la vez la más útil y la más malentendida de JavaScript. De paso cerrarás otra deuda pendiente del Módulo 3: por qué las funciones flecha se comportan de forma distinta a las normales.