Componentes controlados: migrar estados en React

En React, un componente controlado es un input que obtiene su valor desde el estado y actualiza ese estado cada vez que cambia. Si trabajas con formularios y buscadores, entender este patrón te permite manejar la lógica de tu aplicación desde un solo lugar y darle mejor experiencia de usuario.

En el ejemplo del buscador partimos de dos archivos que ya veníamos trabajando: SearchBar y App.jsx. La meta es migrar toda la lógica de estados al componente padre para que el hijo solo reciba props y reaccione a eventos.

Por qué migrar los estados al App.jsx

Hasta este punto, el App.jsx solo tenía un estado: el de search. La idea es traer también el estado de city, que antes vivía dentro del SearchBar, para manejar todo el comportamiento de la aplicación desde el componente padre [00:47].

Cuando centralizas los estados en App.jsx, el SearchBar deja de necesitar el hook useState y sus declaraciones internas. Todo lo que antes era lógica interna ahora entra como props. Esto ordena el código y hace que el flujo de datos sea predecible.

¿Qué es un componente controlado en React? Es un input cuyo valor viene del estado y se actualiza en cada cambio del usuario. El estado es la única fuente de verdad, así que el valor mostrado siempre refleja lo que hay en el estado.

Qué props recibe el SearchBar

Desde el App.jsx le pasamos al SearchBar cinco props que reemplazan toda la lógica que antes tenía adentro [01:20]:

• value: el valor del input, que ahora corresponde al estado city.
• searchValue: el valor de la búsqueda, tomado del estado search.
• onChange: evento al cambiar, ejecuta el setCity.
• onSearch: evento al buscar, ejecuta el setSearch.
• onClear: evento al limpiar, ejecuta setCity y setSearch para dejar ambos estados vacíos.

Con estas props, el SearchBar se vuelve un componente que solo lee y dispara eventos, sin guardar estado propio.

Cómo limpiar los datos de todo el formulario

Antes, la función handleClearSearch vivía dentro del SearchBar. Ahora el App.jsx maneja el onClear seteando los dos estados a vacío, tanto el de city como el de search [02:39].

Esto significa que limpiar ya no afecta solo a un campo: se ejecuta sobre todo el formulario y su estado al mismo tiempo. La experiencia de usuario mejora porque un solo clic reinicia la búsqueda completa.

¿Cómo limpio un formulario controlado en React? Ejecuta las funciones set de cada estado con un valor vacío desde una sola prop, por ejemplo onClear. Así reinicias todos los campos a la vez.

Qué valores hay que actualizar en el SearchBar

Al quitar el estado local, el editor avisa que hay referencias rotas y el render desaparece. Esto pasa porque se están usando cosas que ya no están definidas, como en clases anteriores [03:35]. Para recuperar la interfaz, ajustamos cada valor:

• El setCity ya no existe, se reemplaza por onChange.
• La validación del botón deja de usar city o searchCity y pasa a usar value o searchValue.
• El onClick de limpiar usa la prop onClear en vez de la función clearSearch borrada.
• El value del primer input toma la prop value en lugar de city.
• En la sección de resultados, searchCity se reemplaza por searchValue [05:16].

Después de reemplazar esas referencias y guardar, la interfaz vuelve a aparecer y todas las cinco props quedan en uso.

Cómo probar que la funcionalidad sigue viva

Una vez ordenado el código, toca verificar que nada se rompió. Al buscar Bariloche y hacer clic en buscar, el filtro responde y muestra los resultados. Si borramos el texto, la funcionalidad se mantiene [05:38].

Ese pequeño test confirma dos cosas: el buscador quedó más ordenado y toda la interfaz ahora funciona con componentes controlados. La función del formulario se reduce a hacer preventDefault y ejecutar onSearch con el valor y el trim aplicado [02:20].

¿Dónde debe vivir el estado en un formulario React? En el componente padre, para que los hijos reciban valores y eventos como props. Así centralizas la lógica y evitas duplicar estados.

Con esta base, el siguiente reto es extender el patrón. La misión propuesta es sacar el filtro de tipo de la lógica actual y llevarlo al input de tipo, pasando de ciudad a tipo, y luego desarrollar el filtro de huéspedes apoyándote en la lógica ya construida.

En la siguiente clase se introduce useEffect para simular la carga inicial de propiedades. ¿Cuál fue tu approach para resolver los filtros? Cuéntamelo en los comentarios.