Cuando un componente hijo intenta ejecutar una función que vive en el padre, React lanza un error en consola. La solución elegante pasa por eventos personalizados como props, un patrón que mantiene la arquitectura limpia y delega la lógica de estado a quien debe manejarla: el componente padre.

¿Por qué delegar el cambio de estado al componente padre?

El estado general de una aplicación, como la lista de to do's, pertenece al componente padre. Si el hijo intenta modificar ese estado directamente, rompes el principio de responsabilidad y terminas pasando funciones gigantes por props.

La alternativa más limpia es que el hijo dispare eventos y el padre decida qué hacer con ellos. Así, cada componente se concentra en su trabajo: el hijo notifica, el padre actualiza.

¿Qué son los eventos personalizados en React? Son props con prefijo on que reciben una función. El componente hijo las ejecuta cuando ocurre algo internamente, y el padre define la lógica que debe correr.

¿Cómo creo un evento onInputChange en un componente hijo?

La convención dicta que cualquier evento empiece con on, igual que onClick, onChange o onBlur en HTML. Esta práctica viene de frameworks como Bootstrap o Material UI, que exponen componentes JSX con eventos muy personalizados.

En el componente hijo recibes el evento como prop y lo disparas dentro del onChange real del input:

jsx function TodoItem({ onInputChange, onTextChange, onRemove, index, todo }) { return ( <input type="checkbox" onChange={onInputChange} /> ); }

En el padre, defines la lógica del setter y la pasas como función al hijo. El resultado es un componente que delega el evento interno del input al padre y deja la mutación del estado donde corresponde.

¿Cómo paso datos del hijo al padre con onTextChange?

Cuando el evento necesita información extra, como el texto editado, el hijo invoca la función pasándole ese valor como argumento. El padre lo recibe y actualiza el estado con produce de Immer.

• onInputChange: cambia el estado completed del to do al hacer clic en el checkbox.
• onTextChange: recibe el texto editado y lo escribe en el índice correspondiente.
• onRemove: ejecuta removeTodo con el índice para hacer un splice del elemento.

El onBlur del modo editable cumple doble función: quita la edición del elemento y dispara onTextChange para guardar el cambio. Ahí ves la potencia de la composición funcional: encadenas comportamientos sin acoplar componentes.

¿Cuándo uso onRemove en lugar de llamar a la función directa? Siempre que la acción modifique el estado global. El hijo emite el evento, el padre ejecuta removeTodo(index) y el árbol se mantiene desacoplado.

¿Cómo conecto onRemove desde App.jsx?

En App.jsx, donde renderizas la lista, defines el evento como una función inline que recibe el índice del elemento actual:

jsx <TodoItem onInputChange={() => setTodos(/* lógica /)} onTextChange={(text) => setTodos(/ lógica con text */)} onRemove={() => removeTodo(index)} />

Al refrescar la app, todo sigue funcionando: agregas elementos, cambias su estado completed, editas textos con contentEditable y eliminas ítems. La propiedad derivada con useMemo continúa contando correctamente los elementos completados.

¿Qué falta para que la app guarde datos del usuario?

Ahora mismo, si cambias el dark mode, marcas tareas como completadas o agregas nuevos to do's y refrescas, todo se pierde. El estado vive solo en memoria.

La solución viene en la próxima clase con localStorage, una API del navegador que persiste datos entre sesiones. Vas a aprender a sincronizar el estado de React con el almacenamiento local para que la experiencia del usuario se mantenga al recargar.

¿Ya identificaste en tu propio proyecto qué eventos personalizados podrías crear para limpiar la comunicación entre componentes? Cuéntame en los comentarios cómo estás manejando el flujo de datos en tu app.