JavaScript de Cero a Experto / Proyectos + retos

Proyecto: buscador con API, búsqueda en vivo y paginación

Proyecto180 min150 XP

"Mi Bolsillo" vivía en tu navegador; este proyecto sale a internet. Un buscador que consulta una API real MIENTRAS escribes, con paginación, estados de carga y cancelación de búsquedas viejas. Son los patrones exactos de cualquier app que muestra datos de un servidor —de Spotify a tu futuro dashboard en el trabajo.

Reto

Buscador con API y paginación

Difícil180 min150 XP(×2 sin mirar la solución)

Qué debes construir

Un buscador de publicaciones sobre la API pública jsonplaceholder.typicode .com/posts (100 posts de prueba, CORS abierto, sin llave). Debe:

Buscar mientras escribes, pero con debounce: no una petición por tecla, sino una tras una breve pausa al dejar de escribir.
Paginar: mostrar de a 8 resultados con botones "Anterior / Siguiente".
Mostrar los tres estados (módulo 10): cargando, error y resultados (incluido el "sin resultados").
Cancelar búsquedas viejas con AbortController: si escribes rápido, la respuesta de una búsqueda anterior no debe pisar la nueva.

Requisitos concretos:

Debounce de ~400ms en el input: escribe "hola" rápido → una sola petición, no cuatro. (Aquí usas una versión simple; lo construyes a fondo en los retos del módulo.)
URL con parámetros: ?q=<término>&_page=<n>&_limit=8. La API filtra y pagina por ti en el servidor.
Paginación honesta sin depender de headers: "Siguiente" se deshabilita cuando llegan menos de 8 resultados (última página); "Anterior", en la página 1.
response.ok: un 404/500 NO rechaza el fetch (la trampa del módulo 10) → chequea y lanza tú.
Cancelación: cada búsqueda nueva aborta la anterior; el AbortError jamás se muestra como error al usuario.

Reglas

Datos de la API al DOM con textContent/createElement, nunca innerHTML (módulo 7: viene de fuera, es dato no confiable).
Los tres estados son excluyentes: o cargando, o error, o resultados.
Guard iniciar() con DOMContentLoaded.
La búsqueda vacía puede mostrar los primeros posts (sin q) o un estado inicial —tú decides, pero sé consistente.

180:00

Cuando estés listo, arranca el reloj.

Los tres patrones profesionales que este proyecto ensaya:

Debounce = respeto por el servidor (y por el usuario). Sin él, "medellín" son ocho peticiones que compiten y desperdician red. Con él, una sola cuando el usuario termina de pensar. Toda barra de búsqueda seria lo tiene.
Cancelar lo viejo evita el bug de la carrera. Sin AbortController, una respuesta lenta de una búsqueda anterior puede llegar DESPUÉS de la nueva y pisar resultados correctos con viejos. Abortar la anterior mata esa carrera de raíz —uno de esos bugs que solo aparecen con mala conexión y enloquecen a quien no conoce este patrón.
Los tres estados, siempre. Cargando, error y datos no son opcionales: son el contrato de toda UI que habla con un servidor. El usuario nunca debe quedarse mirando una pantalla muerta sin saber si algo pasa.

Autoevaluación: escribe rápido y mira la pestaña de red de las DevTools —¿sale UNA petición por pausa, no una por tecla? Navega páginas: ¿"Siguiente" se apaga en la última, "Anterior" en la primera? Y la prueba dorada de la cancelación: con la red lenta (DevTools → Network → throttling), escribe y borra rápido —los resultados que quedan deben ser los de tu ÚLTIMA búsqueda, nunca los de una vieja que llegó tarde. Si eso funciona, dominas el patrón que hace que las apps con datos remotos se sientan sólidas.

Nota honesta: jsonplaceholder.typicode.com es un servidor de prueba público; si algún día cambia o cae, este playground fallaría —y ahí verías tu estado de error funcionando de verdad. En un proyecto tuyo, esa API es la de tu backend.

Qué sigue

Estado local, datos remotos… falta el tercer sabor de app: la interactiva con tiempo. El último proyecto es un juego de trivia con temporizador, puntaje y una máquina de estados (módulo 13) que orquesta menú → jugando → resultado. La lógica de juego que sostiene desde un quiz hasta un Wordle.