native-data-fetching

Visión general de la skill native-data-fetching

En qué ayuda realmente native-data-fetching

La skill native-data-fetching es una guía enfocada en Expo para implementar y depurar solicitudes de red en apps de React Native y Expo. Resulta especialmente útil cuando necesitas algo más que un prompt genérico de “escribe una llamada a fetch”: peticiones a API, cabeceras de autenticación, decisiones de caché, comportamiento offline, base URLs por entorno y loaders de datos de Expo Router entran dentro de su alcance.

Mejor encaje para equipos de Frontend Development

native-data-fetching for Frontend Development encaja muy bien si estás desarrollando funcionalidades móviles o de Expo web que dependen de datos remotos y quieres seguir convenciones alineadas con el ecosistema Expo. Es especialmente relevante para desarrolladores que están decidiendo entre fetch puro, una librería de datos como React Query o SWR, y loaders a nivel de ruta en Expo Router.

Trabajo real que resuelve

Normalmente, los usuarios intentan hacer una de estas cuatro cosas:

• lanzar una integración de API fiable
• corregir un flujo de red roto o inestable
• elegir un patrón de fetching razonable para una pantalla o ruta
• evitar errores habituales específicos de Expo relacionados con config, auth y loaders

Aquí es donde la skill native-data-fetching aporta más valor que una revisión superficial del repo: plantea el networking como una decisión de implementación, no solo como un fragmento de código.

Diferenciadores clave y limitaciones

Su principal diferenciador es una alineación explícita con Expo. La fuente prefiere de forma clara expo/fetch frente a axios, y va más allá de las solicitudes básicas para cubrir caché, soporte offline, manejo de tokens y loaders de Expo Router. También incluye una referencia específica sobre useLoaderData y el modelo de ejecución server/static para Expo web en SDK 55+.

La principal limitación: no es un framework de networking completo. Es un documento-skill con guía y ejemplos, así que el resultado depende mucho de la calidad del prompt y de si la arquitectura de tu app ya está suficientemente clara.

Cómo usar la skill native-data-fetching

Contexto de instalación de native-data-fetching

Instala la skill desde el repositorio de skills de Expo:

npx skills add https://github.com/expo/skills --skill native-data-fetching

Después de instalarla, lee primero esto:

• SKILL.md
• references/expo-router-loaders.md

Ese orden de lectura te da primero la guía general de networking y después el modelo especial de loaders para apps web con Expo Router.

Cuándo invocar la skill native-data-fetching

Usa la native-data-fetching skill siempre que la tarea incluya:

• llamar a una API externa
• enviar datos de formulario o JSON
• añadir cabeceras de auth o lógica de refresh de tokens
• depurar timeouts, errores HTTP o respuestas mal formadas
• decidir entre fetch puro, React Query, SWR o loaders
• gestionar comportamiento offline o de caché
• configurar URLs de API basadas en el entorno
• implementar carga de datos a nivel de ruta con Expo Router

Si la tarea toca estado de red, ciclo de vida de requests o arquitectura de datos remotos, conviene invocarla pronto en lugar de esperar a que aparezcan bugs.

Qué información necesita la skill de tu parte

Obtendrás mejores resultados si proporcionas:

• la pantalla, ruta o funcionalidad que estás construyendo
• el runtime objetivo: iOS, Android, web o los tres
• el tipo de request: GET, POST, flujo de mutación, polling, preload, etc.
• detalles de la API: forma del endpoint, modelo de auth, respuesta esperada, contrato de error
• si los datos deben cachearse, refrescarse, reintentarse o funcionar offline
• si usas Expo Router, React Query, SWR o estado React puro
• cualquier configuración de entorno o reglas de base URL que ya existan en la app

Sin ese contexto, la skill puede seguir generando código, pero puede elegir un patrón de fetching incorrecto.

Cómo convertir un objetivo difuso en un prompt sólido

Prompt débil:

Fetch user data for my screen.

Prompt más sólido:

Use native-data-fetching to implement a profile screen in an Expo app.
Target platforms: iOS and Android.
Need: authenticated GET /me request with Bearer token, loading state, 401 handling, retry on network failure, and stale data shown while refetching.
Current stack: Expo Router + React Query.
Return: recommended pattern, code, and where to place config for the API base URL.

La versión más sólida funciona mejor porque da a la skill suficiente información para decidir entre lógica directa con fetch, una librería de queries y patrones conscientes de la ruta.

Cómo elegir el patrón de fetching adecuado con native-data-fetching

Un recorrido práctico de decisión:

• Usa fetch puro o expo/fetch para requests puntuales y flujos simples.
• Usa React Query o SWR cuando importen la invalidación de caché, el refresco en segundo plano y la deduplicación de requests.
• Usa loaders de Expo Router cuando la ruta deba cargar datos antes del render en Expo web, especialmente en SDK 55+.

Este es uno de los usos de mayor valor de la native-data-fetching guide: pedirle que recomiende un patrón antes de implementar.

Advertencia sobre el uso de loaders en Expo Router

La referencia incluida importa si estás usando useLoaderData. Los loaders en Expo Router web tienen un modelo de ejecución dual:

• en la carga inicial de la página, pueden ejecutarse del lado del servidor
• en la navegación del lado del cliente, el navegador obtiene los datos del loader por HTTP

Eso significa que el contexto de la request, el hosting y la configuración cambian entre los modos de salida "server" y "static". Si tu tarea menciona loaders, incluye:

• versión de Expo SDK
• modo de salida web
• si necesitas acceso a headers/cookies/request
• modelo de hosting

Si no lo haces, la solución generada puede asumir capacidades que tu configuración no tiene.

Ruta de lectura del repositorio que ahorra tiempo

Para una revisión rápida de native-data-fetching usage, no navegues el repo al azar. Sigue esta ruta:

1. SKILL.md para alcance y preferencias
2. references/expo-router-loaders.md si tu app usa carga de datos con Expo Router
3. el cliente API, utilidades de auth y archivos de configuración de entorno de tu propia app

La skill upstream es lo bastante breve como para que el cuello de botella no suela ser leerla, sino mapearla correctamente a la arquitectura actual de tu app.

Flujo de trabajo práctico para implementar

Un buen flujo de trabajo es:

1. pedir una recomendación de patrón
2. pedir la capa de requests o el hook concreto
3. añadir estados de error/carga/vacío
4. añadir manejo de auth y entorno
5. probar casos de fallo
6. solo entonces añadir mejoras de caché/offline si hacen falta

Esto evita sobreingeniería. Muchos equipos saltan directamente a caché avanzada antes de confirmar que el endpoint, la auth y el comportamiento de la base URL funcionan bien.

Preferencias que afectan al código generado

La fuente dice explícitamente que hay que evitar axios y preferir expo/fetch. Si aun así pides axios, estarás yendo contra la preferencia declarada de la skill. Si tu codebase ya está estandarizado sobre axios, indícalo claramente para que la salida se adapte en lugar de chocar con tu stack.

Detalles de request habituales que conviene especificar desde el principio

Para obtener un primer borrador utilizable, incluye estos detalles de implementación:

• JSON frente a multipart/form-data
• headers obligatorios
• origen del token y comportamiento de refresh
• expectativas de timeout o retry
• si las respuestas no 2xx devuelven cuerpos de error en JSON
• si la UI debe bloquear, hacer stream o renderizar primero datos obsoletos

Estos detalles suelen importar más que la propia ruta del endpoint.

FAQ de la skill native-data-fetching

¿native-data-fetching es solo para apps Expo?

Aporta más valor en contextos de Expo y React Native, especialmente por la preferencia por expo/fetch y la referencia sobre loaders de Expo Router. Algunos patrones de fetch son conocimiento general de web, pero la skill está claramente ajustada al ecosistema Expo.

¿native-data-fetching es apta para principiantes?

Sí, si tu objetivo es concreto. Los principiantes pueden usar bien la native-data-fetching skill cuando describen la pantalla, el endpoint y el comportamiento esperado. Resulta menos útil para aprendizaje totalmente abierto, porque asume que estás implementando o depurando algo de forma activa.

¿En qué se diferencia de un prompt de programación normal?

Un prompt genérico puede devolverte código de fetch funcional, pero pasar por alto decisiones específicas del ecosistema, como preferir expo/fetch, usar el modelo correcto de carga de datos o tener en cuenta el comportamiento de los loaders de Expo Router. La native-data-fetching guide es mejor cuando el encaje con la arquitectura y el framework importa tanto como la sintaxis.

¿Cuándo no debería usar native-data-fetching?

No recurras a ella si tu tarea no está relacionada con datos remotos, por ejemplo estado solo local, estilos de UI, animaciones o navegación que no haga fetch de nada. Además, si necesitas un diseño completo de API backend o un plan avanzado de infraestructura de servidor, esta skill se queda corta.

¿Debería usarla si ya tengo React Query o SWR?

Sí. De hecho, ese es un caso de uso muy sólido. Indica a la skill qué librería usas ya y si quieres conservar las query keys actuales, la estrategia de invalidación y las reglas de caché. La guía es más útil cuando amplía tu capa de datos actual en lugar de reemplazarla.

¿native-data-fetching cubre por completo los loaders de Expo Router?

Cubre los puntos de decisión importantes para adoptarlos y enlaza a una referencia específica, pero no todos los casos límite. Si los loaders son centrales en tu app, revisa references/expo-router-loaders.md directamente para entender los detalles de configuración y ejecución antes de implementar comportamiento de producción.

Cómo mejorar la skill native-data-fetching

Da a native-data-fetching contexto arquitectónico, no solo endpoints

La mayor mejora de calidad llega cuando le dices a la skill dónde vive la request dentro de tu app:

• componente
• custom hook
• capa de queries
• route loader
• cliente API compartido

Eso le permite generar código que encaja con tu estructura en vez de un snippet aislado.

Pide decisiones antes que código

Un patrón sólido es:

Use native-data-fetching to choose the best approach for this feature.
Compare plain fetch vs React Query vs Expo Router loader for my constraints.
Then implement the winning option.

Esto reduce retrabajo porque la primera respuesta se convierte en una decisión de diseño, no solo en código generado.

Incluye los modos de fallo que realmente te importan

Si no mencionas cómo quieres manejar fallos, a menudo obtendrás solo ejemplos optimistas. Mejora los resultados nombrando preocupaciones reales:

• expiración de token con 401
• dispositivo offline
• conexiones lentas
• requests duplicadas al enfocar la pantalla
• payloads JSON inválidos
• errores 500 del servidor con mensajes de error

Estas restricciones empujan a la skill hacia una salida más preparada para producción.

Modo de fallo habitual: suposiciones vagas sobre la plataforma

Muchos malos consejos de networking vienen de mezclar supuestos de nativo y web. Sé explícito sobre:

• solo nativo
• solo web
• app universal
• Expo Router web con loaders
• export estático frente a renderizado en servidor

Esto importa porque el comportamiento de loaders, el contexto de request y las restricciones de hosting cambian entre estas configuraciones.

Modo de fallo habitual: configuración y manejo de base URL poco claros

Si omites detalles del entorno, el código generado puede hardcodear URLs o colocar la configuración en la capa incorrecta. Proporciona:

• reglas de base URL para dev/staging/prod
• si las variables de entorno ya existen
• dónde vive ahora la configuración
• si las requests cambian según la plataforma

Eso hace que la instalación y adopción de native-data-fetching sean mucho más fluidas en una app real.

Mejora la calidad de salida con contratos de respuesta realistas

Mejor que decir “returns user data”:

GET /me returns 200 { id, name, avatarUrl }.
401 returns { error: "token_expired" }.
500 may return HTML from an upstream proxy.

Esto ayuda a la skill a generar parsing y manejo de errores más seguros, algo especialmente útil al depurar APIs inestables.

Itera después de la primera respuesta

Después de la salida inicial, pide seguimientos como:

• convert this to React Query
• adapt this to Expo Router loader usage
• add optimistic mutation handling
• refactor into a reusable API client
• harden error states for offline mode

La primera respuesta debería fijar el patrón; en los siguientes turnos, debería alinearse con las restricciones reales de tu app.

Lee la referencia de loaders cuando importe el renderizado web

Si tu proyecto usa carga de datos a nivel de ruta, la mejora más rápida es leer references/expo-router-loaders.md y luego hacer prompts con su terminología: useLoaderData, "server" frente a "static", acceso a request y modelo de hosting. Eso produce una salida de native-data-fetching usage mucho más precisa que una petición genérica de “cargar datos antes del render”.

Mantén native-data-fetching centrada en trabajo de networking

La skill funciona mejor cuando el prompt se mantiene centrado en aspectos de datos remotos. Si mezclas networking, gestión de estado, rediseño de UI y reestructuración de navegación en una sola petición, el resultado suele volverse superficial. Divide el trabajo para que native-data-fetching resuelva primero con claridad la API y la capa de datos.