Aprender a conectar un provider con un servicio externo y agregar animaciones con React Confetti te permite enriquecer tu aplicación de hábitos con retroalimentación visual. Si estás construyendo con React Native y context, aquí verás cómo lanzar confeti y mensajes aleatorios cada vez que completas un hábito, simulando una llamada a una API real.
Este contenido es ideal para quienes ya trabajan con context y quieren dar el siguiente paso hacia servicios y animaciones dinámicas.
Cómo conecto el provider con el explorer usando context
Antes de animar cualquier cosa, el reto de la clase anterior consistía en cambiar la forma de agregar hábitos. En lugar de usar el addHabit directamente desde el explorer, ahora lo haces a través del context que ya tenías.
La solución es sencilla: importas addHabit desde useHabit y lo llamas entregando el título y la prioridad. No cambia nada visualmente porque ya estabas llamando un pick, solo agregas esa línea con addHabit [00:48].
El resultado es directo: lo que seleccionas en los hábitos sugeridos se agrega automáticamente a los hábitos personales de la persona y lo ves reflejado en el home [01:16].
¿Qué hace un provider en React? Es un componente que envuelve tu aplicación y comparte estado o funcionalidad con todos sus componentes hijos sin tener que pasar props manualmente. Funciona como el centro de control de una funcionalidad.
Cómo agrego animación con React Confetti y un nuevo provider
La animación se construye con la librería React Confetti, que instalas con el comando que aparece en los recursos de la clase [01:33].
Luego creas un nuevo provider dedicado al confeti. Piensa en él como el centro de control de ese movimiento. Dentro defines varios state para controlar su comportamiento:
- Un estado para hacer la animación visible o no.
- Un mensaje específico que se muestra cada vez que completas un hábito.
- La duración de la animación y cuándo inicia y finaliza.
Ese control de inicio y fin es clave: evita sobreescribir una animación encima de otra [02:19]. Para cubrir toda la pantalla, colocas un confeti al lado izquierdo y otro al derecho alrededor del hábito completado [02:33].
Cómo creo un servicio que simula una llamada a una API
Aquí viene la parte interesante. Vas a simular la creación de un servicio, como si llamaras datos desde fuera de tu proyecto.
Primero creas una carpeta de servicios con un archivo motivation.ts. Dentro generas un mock local con varios mensajes que aparecerán junto a la animación [03:06]. La idea es simular que haces una llamada a un endpoint real.
¿Qué es un mock en desarrollo? Es un conjunto de datos falsos o simulados que imitan la respuesta de una API real. Te permite construir y probar funcionalidad sin depender de un servidor externo.
La lógica de fetch sigue estos pasos:
- Guardas la URL del endpoint usando
process y las environments del proyecto [03:35].
- Verificas con un condicional si existe esa URL o endpoint.
- Dentro de un
try catch, haces un fetch pasando la URL y el body necesario.
- Configuras el body con una llamada post que envía un nombre y el título del hábito [04:09].
Después verificas si la respuesta es correcta. Si la respuesta es diferente de ok, usas throw error con el mensaje de que el endpoint falló, para poder detectarlo [04:28].
Cómo proceso la respuesta y manejo los errores
Una vez que tienes respuesta, almacenas la data esperando el resultado del fetch y lo conviertes a JSON para leer la información [04:45].
El mensaje que mostrarás en la animación sale de esa data. Preguntas si existe la data: si existe, traes el mensaje; si no, devuelves un string vacío. Todo lo conviertes con toString porque es lo que se muestra en la etiqueta del mensaje [05:08].
Si algo falla, el catch retorna un mensaje desde tu mock local en la posición cero y registra el error con un warn en la consola [05:40]. Así tu aplicación nunca se queda sin mensaje que mostrar.
Cómo implemento el confeti al completar un hábito
Con el servicio listo, importas el provider de confeti igual que antes, procurando que sea la etiqueta padre de todo tu stack, que en este caso son tus tabs [06:12].
En el index creas una constante que trae toda la funcionalidad del provider de Celebrate. Ya tenías un toggleHabit, pero ahora creas una nueva función asíncrona que lanza el confeti cada vez que completas un hábito [06:40].
Dentro de esa función la lógica es:
- Preguntas si completaste el hábito hoy usando
lastDoneAt comparado con la fecha actual [07:08].
- Si es el mismo día, asignas la fecha actual; en caso contrario, colocas
false.
- Llamas el
toggleHabit del context entregando el ítem con su id [07:30].
- Con un
if negado, muestras el mensaje de motivación que traes desde el servicio [07:45].
Un detalle importante: en el render de las tarjetas, en lugar de pasar un any al listRenderItem, siempre pasa el habit tipado correctamente [08:00]. Y en vez de indicar si está completo, pasas si se hizo el día de hoy, llamando ahí la función que lanza el confeti [08:19].
¿Por qué no debo usar any en TypeScript? Porque any desactiva la verificación de tipos y pierdes la seguridad que ofrece TypeScript. Tipar con tu modelo real, como habit, previene errores y hace tu código más predecible.
Si no ves el cambio, corre una R en la terminal para recargar la aplicación [08:36]. Al seleccionar un hábito completado hoy, verás la animación con un mensaje diferente cada vez, gracias al fetch que pasa por el provider [08:51].
¿Qué otra funcionalidad animarías con este mismo patrón de provider y servicio? Cuéntame en los comentarios cómo lo aplicarías en tu propio proyecto.
