native-data-fetching

Visão geral da skill native-data-fetching

O que native-data-fetching realmente ajuda a resolver

A skill native-data-fetching é um guia focado em Expo para implementar e depurar requisições de rede em apps React Native e Expo. Ela é mais útil quando você precisa de algo além de um prompt genérico de “escreva um fetch”: chamadas de API, headers de autenticação, decisões de cache, comportamento offline, base URLs por ambiente e loaders de dados do Expo Router entram no escopo.

Melhor encaixe para equipes de Frontend Development

native-data-fetching for Frontend Development é uma ótima escolha se você está criando recursos mobile ou Expo web que dependem de dados remotos e quer seguir convenções alinhadas ao ecossistema Expo. Ela é especialmente relevante para quem está decidindo entre fetch puro, uma biblioteca de dados como React Query ou SWR, e loaders em nível de rota no Expo Router.

O trabalho real que ela resolve

Em geral, quem usa essa skill está tentando fazer uma destas quatro coisas:

• entregar uma integração de API confiável
• corrigir um fluxo de rede quebrado ou instável
• escolher um padrão de fetching sensato para uma tela ou rota
• evitar erros comuns no Expo ligados a config, auth e loaders

É aqui que a skill native-data-fetching é mais útil do que uma leitura rápida do repositório: ela trata networking como uma decisão de implementação, não só como um trecho de código.

Diferenciais e limitações principais

O principal diferencial é o alinhamento opinativo com Expo. A fonte prefere explicitamente expo/fetch em vez de axios, e vai além de requisições básicas ao cobrir cache, suporte offline, tratamento de tokens e loaders do Expo Router. Ela também traz uma referência objetiva sobre useLoaderData e sobre o modelo de execução server/static para Expo web no SDK 55+.

A principal limitação: isso não é um framework completo de networking. É um documento de skill com orientação e exemplos, então o resultado depende bastante da qualidade do prompt e de a arquitetura do seu app já estar minimamente clara.

Como usar a skill native-data-fetching

Contexto de instalação de native-data-fetching

Instale a skill a partir do repositório de skills do Expo:

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

Depois da instalação, leia isto primeiro:

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

Essa ordem de leitura te dá primeiro a orientação geral de networking e, em seguida, o modelo especial de loaders para apps web com Expo Router.

Quando acionar a skill native-data-fetching

Use a native-data-fetching skill sempre que a tarefa envolver:

• chamar uma API externa
• enviar dados de formulário ou JSON
• adicionar headers de autenticação ou lógica de refresh de token
• depurar timeouts, erros HTTP ou respostas malformadas
• escolher entre fetch puro, React Query, SWR ou loaders
• lidar com comportamento offline/cache
• configurar URLs de API por ambiente
• implementar carregamento de dados por rota no Expo Router

Se a tarefa toca em estado de rede, ciclo de vida de requisições ou arquitetura de dados remotos, vale acionar a skill cedo, em vez de só depois que os bugs aparecerem.

Quais informações a skill precisa de você

Você terá uma resposta melhor se informar:

• a tela, rota ou funcionalidade que está sendo criada
• o alvo de runtime: iOS, Android, web ou os três
• o tipo de requisição: GET, POST, fluxo de mutation, polling, preload etc.
• detalhes da API: formato do endpoint, modelo de auth, resposta esperada, contrato de erro
• se os dados precisam de cache, refresh, retry ou suporte offline
• se você usa Expo Router, React Query, SWR ou estado React puro
• qualquer regra de config de ambiente ou base URL já existente no app

Sem esse contexto, a skill ainda consegue gerar código, mas pode escolher o padrão de fetching errado.

Como transformar um objetivo vago em um prompt forte

Prompt fraco:

Fetch user data for my screen.

Prompt melhor:

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.

A versão mais forte funciona melhor porque dá à skill informação suficiente para escolher entre lógica direta com fetch, uma biblioteca de query e padrões orientados por rota.

Como escolher o padrão de fetching certo

Um caminho prático de decisão:

• Use fetch puro ou expo/fetch para requisições pontuais e fluxos simples.
• Use React Query ou SWR quando invalidação de cache, atualização em segundo plano e deduplicação de requisições forem importantes.
• Use loaders do Expo Router quando a rota precisar carregar dados antes do render no Expo web, especialmente no SDK 55+.

Esse é um dos usos de maior valor do native-data-fetching guide: pedir uma recomendação de padrão antes de implementar.

Ressalva importante sobre loaders do Expo Router

A referência incluída é importante se você estiver usando useLoaderData. Os loaders no Expo Router web têm um modelo duplo de execução:

• no carregamento inicial da página, eles podem rodar no servidor
• na navegação client-side, o navegador busca os dados do loader via HTTP

Isso significa que contexto da requisição, hospedagem e configuração mudam entre os modos de saída "server" e "static". Se sua tarefa mencionar loaders, inclua:

• versão do Expo SDK
• modo de output web
• se você precisa de acesso a headers/cookies/request
• modelo de hospedagem

Sem isso, a solução gerada pode presumir capacidades que sua configuração não oferece.

Caminho de leitura do repositório que economiza tempo

Para uma revisão rápida de native-data-fetching usage, não navegue pelo repositório aleatoriamente. Siga este caminho:

1. SKILL.md para entender escopo e preferências
2. references/expo-router-loaders.md se seu app usa carregamento de dados com Expo Router
3. o client de API, utilitários de auth e arquivos de config de ambiente do seu próprio app

A skill upstream é curta o bastante para que o gargalo normalmente não seja lê-la, e sim mapear corretamente a orientação para a arquitetura atual do seu app.

Fluxo prático de implementação

Um bom fluxo é:

1. pedir uma recomendação de padrão
2. pedir a camada concreta de requisição ou hook
3. adicionar estados de erro/loading/vazio
4. adicionar auth e tratamento de ambiente
5. testar casos de falha
6. só então adicionar melhorias de cache/offline, se necessário

Isso evita overengineering. Muitas equipes partem direto para cache avançado antes de confirmar se endpoint, auth e comportamento da base URL já estão funcionando como deveriam.

Preferências que afetam o código gerado

A fonte diz explicitamente para evitar axios e preferir expo/fetch. Se você pedir axios mesmo assim, estará indo contra a preferência declarada da skill. Se seu codebase já padroniza axios, deixe isso claro para que a resposta se adapte, em vez de entrar em conflito com sua stack.

Detalhes comuns de requisição para especificar logo de início

Para receber um primeiro rascunho realmente útil, inclua estes detalhes de implementação:

• JSON vs multipart/form-data
• headers obrigatórios
• origem do token e comportamento de refresh
• expectativa de timeout ou retry
• se respostas não-2xx retornam corpo de erro em JSON
• se a UI deve bloquear, fazer streaming ou renderizar dados stale primeiro

Esses detalhes costumam importar mais do que o próprio caminho do endpoint.

FAQ da skill native-data-fetching

native-data-fetching serve apenas para apps Expo?

Ela tem mais valor em contextos Expo e React Native, especialmente por causa da preferência por expo/fetch e da referência aos loaders do Expo Router. Alguns padrões de fetch são conhecimento geral de web, mas a skill é claramente ajustada para o ecossistema Expo.

native-data-fetching é amigável para iniciantes?

Sim, desde que o objetivo seja concreto. Iniciantes conseguem usar bem a native-data-fetching skill quando descrevem a tela, o endpoint e o comportamento esperado. Ela ajuda menos em aprendizado totalmente aberto, porque parte do princípio de que você está implementando ou depurando algo de fato.

Em que isso difere de um prompt comum de código?

Um prompt genérico pode até devolver um código de fetch funcional, mas ignorar escolhas específicas do ecossistema, como preferir expo/fetch, usar o modelo certo de carregamento de dados ou considerar o comportamento dos loaders do Expo Router. O native-data-fetching guide é melhor quando arquitetura e aderência ao framework importam tanto quanto a sintaxe.

Quando eu não deveria usar native-data-fetching?

Não recorra a ela se sua tarefa não tiver relação com dados remotos, como estado apenas local, styling de UI, animações ou navegação que não faz fetch de nada. E, se você precisa de um desenho completo de API backend ou de um plano avançado de infraestrutura server-side, essa skill é estreita demais.

Vale usar mesmo se eu já tiver React Query ou SWR?

Sim. Na verdade, esse é um caso de uso forte. Informe à skill qual biblioteca você já usa e se quer preservar query keys existentes, estratégia de invalidação e regras de cache. A orientação é mais útil quando ela estende sua camada de dados atual, em vez de substituí-la.

native-data-fetching cobre loaders do Expo Router por completo?

Ela cobre os principais pontos de decisão para adoção e aponta para uma referência focada, mas não todos os edge cases. Se loaders são centrais no seu app, inspecione references/expo-router-loaders.md diretamente para entender detalhes de configuração e execução antes de implementar comportamento de produção.

Como melhorar o uso da skill native-data-fetching

Dê contexto arquitetural para native-data-fetching, não só endpoints

O maior salto de qualidade vem de dizer à skill onde a requisição vive no seu app:

• component
• custom hook
• query layer
• route loader
• shared API client

Isso permite que ela produza código compatível com sua estrutura, em vez de um snippet solto.

Peça decisões antes de pedir código

Um padrão forte é:

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.

Isso reduz retrabalho, porque a primeira resposta vira uma decisão de design, não apenas código gerado.

Inclua os modos de falha com que você realmente se importa

Se você não mencionar tratamento de falhas, muitas vezes receberá apenas exemplos otimistas. Para melhorar o resultado, nomeie preocupações reais:

• expiração de token com 401
• dispositivo offline
• conexões lentas
• requisições duplicadas ao focar a tela
• payloads JSON inválidos
• erros 500 do servidor com mensagens de erro

Essas restrições empurram a skill para uma saída mais próxima de produção.

Falha comum: suposições vagas sobre plataforma

Muita orientação ruim sobre networking vem de misturar premissas de nativo e web. Seja explícito sobre:

• apenas nativo
• apenas web
• app universal
• Expo Router web com loaders
• export estático vs renderização no servidor

Isso importa porque comportamento de loaders, contexto da requisição e restrições de hospedagem mudam entre esses cenários.

Falha comum: config e tratamento de base URL pouco claros

Se você omitir detalhes de ambiente, o código gerado pode fixar URLs no código ou colocar a config na camada errada. Informe:

• regras de base URL para dev/staging/prod
• se variáveis de ambiente já existem
• onde a config vive hoje
• se as requisições mudam por plataforma

Isso torna o caminho de native-data-fetching install e adoção muito mais suave em um app real.

Melhore a qualidade da resposta com contratos de resposta realistas

Melhor do que dizer “returns user data”:

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

Isso ajuda a skill a gerar parsing e tratamento de erro mais seguros, o que é especialmente útil ao depurar APIs instáveis.

Itere depois da primeira resposta

Depois da resposta inicial, faça follow-ups 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

A primeira resposta deve estabelecer o padrão; as próximas devem alinhá-lo às restrições reais do seu app.

Leia a referência de loaders quando a renderização web importar

Se seu projeto usa carregamento de dados por rota, a melhoria mais rápida é ler references/expo-router-loaders.md e então escrever o prompt usando a terminologia de lá: useLoaderData, "server" vs "static", request access e hosting model. Isso produz uma saída de native-data-fetching usage muito mais precisa do que um pedido genérico como “carregar dados antes do render”.

Mantenha native-data-fetching focada em trabalho de networking

A skill funciona melhor quando o prompt permanece centrado em preocupações de dados remotos. Se você misturar networking, gerenciamento de estado, redesign de UI e reestruturação de navegação em uma única solicitação, o resultado tende a ficar superficial. Separe o trabalho para que native-data-fetching cuide primeiro da API e da camada de dados com clareza.