Simular carga de API con useEffect en React

Cuando trabajas con useEffect en React puedes simular la carga inicial de datos que normalmente llegan desde una API externa. Esto le sirve a cualquier desarrollador frontend que quiera entender cómo manejar efectos secundarios y por qué los datos no siempre aparecen de inmediato en pantalla.

Hasta ahora las propiedades de nuestra aplicación aparecían al instante porque venían de un archivo local que seteamos a mano. Todo estaba dentro del proyecto, sin necesidad de un llamado externo. Pero en una app real eso casi nunca pasa: los datos viajan por la red y tardan un poco en llegar.

¿Qué es una API? Es el servicio externo desde donde tu aplicación obtiene los datos, como un listado de propiedades, en lugar de tenerlos guardados localmente en un archivo.

Por qué necesitas useEffect si los datos ya cargan solos

El problema es que un archivo estático no refleja la realidad. Cuando refrescas la pantalla, las propiedades aparecen al toque porque no hay ningún viaje a un servidor de por medio.

Para acercarnos a un escenario real usamos otro hook nativo de React llamado useEffect. Se importa igual que useState [00:41], y su función es ejecutar código en respuesta a ciertos cambios dentro de la aplicación.

Aquí viene lo interesante: useEffect nos permite controlar cuándo ocurre algo, no solo qué ocurre.

Cómo funciona la estructura de useEffect y su array de dependencias

La estructura básica de useEffect tiene dos partes: una función donde metes el código que quieres ejecutar y un array de dependencias que define cuándo se dispara ese código.

• La función contiene todos los cambios que quieres que se reflejen en tu aplicación.
• El array de dependencias lista los valores de los que depende ese cambio.
• Si algo dentro del array cambia, el efecto se vuelve a ejecutar.

Ese array de dependencias es superimportante. Cuando lo dejas vacío, le estás diciendo a React que ejecute el código una sola vez: la primera vez que la aplicación hace render [01:25].

¿Para qué sirve el array de dependencias en useEffect? Define de qué valores depende el efecto. Si lo dejas vacío, el código corre solo una vez al montar el componente.

Cómo simular el delay de una API con setTimeout

Para imitar la demora real de una API usamos un setTimeout dentro del useEffect. Lo que pongas dentro de ese setTimeout se ejecuta después de un retraso definido en milisegundos.

En el ejemplo empezamos con 1000 milisegundos, es decir, un segundo de espera [01:52]. Dentro de ese tiempo se llama a una función llamada setPropertiesFromAPI, que recibe como valor el listado de properties.

Esa función viene de un nuevo estado que hay que crear:

javascript const [propertiesFromAPI, setPropertiesFromAPI] = useState([]);

useEffect(() => { setTimeout(() => { setPropertiesFromAPI(properties); }, 1000); }, []);

El valor inicial del estado es un array vacío, y eso es justo lo que nos permite simular el delay: al principio no hay nada, y un segundo después aparecen los datos.

Qué cambiar para que la aplicación lea el nuevo estado

Hasta aquí tenemos un estado con valor inicial vacío y un useEffect que corre una vez al cargar la app con un segundo de retraso. Pero falta un detalle clave.

La aplicación no está leyendo properties, sino filteredProperties. Por eso hay que reemplazar el properties que se filtra por el nuevo estado propertiesFromAPI [02:47]. Así el filtrado trabaja sobre los datos que llegan del efecto y no sobre el archivo estático.

Al guardar y refrescar el navegador notas un pequeño delay antes de que aparezcan las propiedades. Si no alcanzas a verlo, sube el número a 4000 milisegundos, o sea cuatro segundos [03:15], y la demora se vuelve evidente.

Por qué cuatro segundos de espera pueden parecer un error

Y aquí surge un problema de experiencia de usuario. Si alguien entra y ve el mensaje "no encontramos alojamientos" durante cuatro segundos o más, va a pensar que algo se rompió.

Esto pasa porque solo tenemos dos estados: cuando no hay propiedades y cuando ya están cargadas. Nos falta manejar el estado de carga para avisarle al usuario que los datos están en camino.

• Estado sin datos: se ve como si no hubiera resultados.
• Estado con datos: las propiedades ya aparecen.
• Estado de carga: todavía no lo tenemos, y es el que evita la confusión.

Ese manejo de estados de carga, error y éxito queda para la siguiente clase, donde mejoramos la experiencia completa.

Si conceptos como setTimeout te suenan borrosos, refuérzalos con el curso de Fundamentos de JavaScript antes de seguir. ¿Ya intentaste cambiar el valor del delay en tu propio proyecto? Cuéntame en los comentarios qué tiempo usaste.