10.5-Análisis de Estados Locales en tu Código

 

Análisis de Estados Locales en tu Código 📝

Excelente ejemplo. Te muestro claramente dónde está cada estado y por qué:

ESTADO LOCAL #1: En App.js

jsx

// EN App.js

const [tasks, setTasks] = useState([]);  // ⭐ ESTADO LOCAL de App

¿Por qué es local?

• Solo el componente App lo maneja directamente

• Se pasa a TaskList como prop (solo lectura para TaskList)

• Si App se desmonta, este estado desaparece

¿Por qué se usa así?

jsx

// Para AGREGAR tareas:

setTasks([...tasks, newTask]); 

// Crea un NUEVO array con todas las tareas + la nueva

// Esto es INMUTABILIDAD (no modificamos el array original)

---

ESTADO LOCAL #2: En TaskForm.js

jsx

// EN TaskForm.js

const [taskText, setTaskText] = useState('');  // ⭐ ESTADO LOCAL de TaskForm

¿Por qué es local?

• Es temporal y efímero: Solo existe mientras escribes en el input

• Solo le importa al formulario mismo

• Se resetea a '' después de enviar

• Si TaskForm se desmonta, este texto desaparece (y está bien)

¿Por qué se usa así?

jsx

// 1. Capturar lo que el usuario escribe

const handleChange = (e) => {

  setTaskText(e.target.value); // Cada tecla actualiza el estado

};

// 2. Input controlado: el valor SIEMPRE viene del estado

<input

  value={taskText}           // ← Estado controla el input

  onChange={handleChange}    // ← Input actualiza el estado

/>

// 3. Limpiar después de enviar

setTaskText('');  // ← Vacía el campo

Visualización del Flujo 🔄

text

Usuario escribe → Estado LOCAL de TaskForm (taskText) 

                  ↓

                  Al enviar: onAddTask(taskText)

                  ↓

                  Estado LOCAL de App (tasks) se actualiza

                  ↓

                  Se pasa como prop a TaskList

                  ↓

                  TaskList muestra las tareas

¿Por qué NO es global este estado?

tasks podría ser global si:

• Necesitaras acceder a las tareas desde componentes muy alejados en el árbol

• Otras partes de la app necesitaran las tareas (notificaciones, estadísticas, etc.)

taskText NUNCA debería ser global porque:

• Es temporal

• Solo le importa al formulario

• Sería como usar un martillo para clavar un alfiler

Ejemplo de lo que sería MALA PRÁCTICA ❌

jsx

// ❌ NO HACER ESTO - Estado global innecesario

// En algún contexto global:

const [taskInputText, setTaskInputText] = useState(''); 

// En TaskForm:

// Ahora todo el mundo sabe lo que estás escribiendo

// ¡Y se renderiza toda la app con cada tecla!

La Filosofía Detrás 🧠

"Levantar el estado" (Lifting State Up)

• tasks está en App porque es el ancestro común más cercano

• App es el único que necesita manejar el array de tareas

• TaskForm y TaskList son "hermanos" que comparten padre (App)

text

     App (tiene tasks)

     /                  \

TaskForm              TaskList

(envía tareas)       (muestra tareas)

Separación de responsabilidades:

• TaskForm: Solo captura input del usuario (estado local temporal)

• App: Almacena y gestiona la lista definitiva (estado local persistente)

• TaskList: Solo muestra (sin estado, solo props)

¿Qué pasa si quisieras marcar tareas como completadas?

Se mantendría local en App, pero actualizarías así:

jsx

// En App.js

const toggleTask = (taskId) => {

  setTasks(tasks.map(task => 

    task.id === taskId 

      ? { ...task, completed: !task.completed }  // Inmutable

      : task

  ));

};

// Y pasarías esta función a TaskList

<TaskList tasks={tasks} onToggle={toggleTask} />

Resumen de tu Código ✅

Componente	Estado Local	Propósito	Duración
App	tasks	Lista maestra de tareas	Persistente
TaskForm	taskText	Texto temporal del input	Efímero
TaskList	Ninguno	Solo muestra (presentacional)	-

Tu código está EXCELENTE porque:

1. ✅ Cada estado está en el lugar correcto

2. ✅ Usas inmutabilidad ([...tasks, newTask])

3. ✅ Los componentes tienen responsabilidades claras

4. ✅ El flujo de datos es unidireccional y predecible

¿Te gustaría que explique cómo convertir este estado local a global usando Context API para que veas la diferencia?