Simular carga de datos con useEffect en React

El hook useEffect en React te permite manejar efectos secundarios como la carga inicial de datos desde una API, algo esencial cuando tus propiedades no vienen de un archivo local sino de un servicio externo que tarda en responder. Si estás construyendo una aplicación real, esto te importa porque los datos casi nunca están listos al instante.

Hasta ahora, las propiedades aparecían de inmediato porque venían de un archivo estático llamado properties, seteado a mano. No había ningún llamado externo, todo vivía dentro de la aplicación. Pero en la vida real los datos llegan desde una API, y aquí es donde entra useEffect para simular esa espera.

Qué es useEffect y para qué sirve en React

useEffect es el segundo hook nativo más importante de React, junto a useState. Lo importas exactamente igual que useState y lo usas para ejecutar código en respuesta a cambios o en el momento en que tu aplicación se renderiza por primera vez.

¿Qué es una API en el contexto de una aplicación React? 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.

La estructura básica del hook tiene dos partes: una función con el bloque de código que quieres ejecutar y un array de dependencias. Dentro de la función metes todos los cambios que quieres que se reflejen. En el array pones los valores de los que depende ese cambio [00:57].

Por qué el array de dependencias es tan importante

El array de dependencias decide cuándo se ejecuta tu efecto. La regla es sencilla:

• El código dentro del efecto se ejecuta cuando algo dentro del array de dependencias sufre un cambio.
• Si dejas el array vacío, el código se ejecuta solo la primera vez que la aplicación hace render.
• Cada valor que agregues al array actúa como un disparador del efecto.

Como en el ejemplo el array está vacío, el bloque corre únicamente en el primer renderizado, justo el comportamiento que necesitamos para simular una carga inicial.

Cómo simular el delay de una API con setTimeout

Para imitar la espera real de una API usamos setTimeout dentro del useEffect. Lo que esté dentro de setTimeout se ejecuta con un retraso igual al valor que le pases al final [01:52].

jsx import { useState, useEffect } from "react";

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

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

Aquí pasa algo clave: el estado propertiesFromAPI arranca con un array vacío como valor inicial. Ese array vacío es lo que nos permite simular el delay que tienen las APIs cuando haces un llamado desde cualquier aplicación [02:37].

¿Por qué el estado inicial es un array vacío? Porque representa el momento en que aún no llegan los datos. Al inicio no hay nada que mostrar, y cuando el setTimeout termina, el array se llena con las propiedades reales.

El setTimeout de 1.000 milisegundos equivale a un segundo de espera. Después de ese segundo, setPropertiesFromAPI guarda el valor de properties, que sigue siendo nuestro archivo estático por ahora.

Qué cambiar para que useEffect realmente funcione

Un detalle fácil de pasar por alto: aunque agregues el useEffect, la aplicación seguía leyendo properties directamente desde el archivo. Para que el efecto tenga sentido, hay que cambiar la fuente que se filtra.

1. Antes, filteredProperties filtraba sobre properties, el valor estático.
2. Ahora debes reemplazar ese properties por tu nuevo estado propertiesFromAPI.
3. Así el filtro trabaja sobre los datos que llegan con retraso, no sobre los estáticos.

Sin este cambio el código estaría ahí, pero la aplicación seguiría leyendo lo que venía de arriba directo, sin usar realmente el hook.

Qué problema de experiencia de usuario aparece con la carga

Al guardar y refrescar el navegador, verás un pequeño delay de un segundo antes de que aparezcan las propiedades. Si el segundo pasa desapercibido, sube el valor a 4.000 milisegundos, o sea cuatro segundos, y el retraso será evidente [03:24].

Y aquí viene lo interesante. Durante esos cuatro segundos, el usuario ve un mensaje de no encontramos alojamientos, y con una espera larga eso parece un error en lugar de una carga. El problema es que por ahora solo manejamos dos estados: cuando no hay propiedades y cuando ya están.

Nos falta setear y manejar los estados de carga, que se abordan en la siguiente etapa junto con los estados de error y éxito para mejorar esa experiencia.

Si conceptos como setTimeout te generan dudas, reforzarlos con el curso de fundamentos de JavaScript te dará una base más sólida antes de seguir avanzando.

¿Ya intentaste subir el delay a varios segundos para ver cómo se comporta tu aplicación? Cuéntame en los comentarios qué estado te gustaría manejar primero: carga, error o éxito.