Plan de la app: descomponer la UI en componentes — Capstone: app de tareas en React

Del boceto al árbol de componentes

Antes de escribir una línea de React, conviene mirar la interfaz y partirla en piezas. Una buena pregunta guía: "¿qué bloques se repiten y qué bloques tienen una responsabilidad clara?". Cada bloque será un componente.

Nuestra mini-app es una lista de tareas (un clásico, y con razón: ejercita props, listas, estado y eventos a la vez). Su pantalla es así:

┌─────────────────────────────┐
│  [ escribe... ]  [ Añadir ] │   ← formulario
├─────────────────────────────┤
│  • Comprar pan       [✔][🗑] │   ← una tarea
│  • Estudiar React    [✔][🗑] │   ← otra tarea
└─────────────────────────────┘

Al observarla aparecen tres responsabilidades naturales:

TareaItem — pinta una tarea: su texto y, si está hecha, tachado. No sabe nada de la lista; solo de la tarea que recibe por props.
ListaTareas — recibe el array de tareas y dibuja un TareaItem (dentro de un <li>) por cada una. Su trabajo es recorrer y delegar.
App — el componente "cerebro": posee el estado (la lista y el texto del input), añade tareas y coordina a los demás.

Regla de oro: el estado vive lo más arriba posible, en el componente que necesita coordinar. Los hijos (TareaItem, ListaTareas) son en su mayoría presentacionales: reciben datos por props y los pintan.

El modelo de datos

Antes que los componentes, decide cómo se representan los datos. Una tarea es un objeto sencillo:

// una tarea
{ id: 1, texto: "Comprar pan", hecha: false }

Y la lista completa es un array de esos objetos:

const tareas = [
  { id: 1, texto: "Comprar pan", hecha: false },
  { id: 2, texto: "Estudiar React", hecha: true },
];

El id es importante: nos servirá como key al renderizar la lista y para identificar qué tarea marcar o borrar.