native-data-fetching

Vue d’ensemble de la skill native-data-fetching

Ce que native-data-fetching apporte concrètement

La skill native-data-fetching est un guide centré sur Expo pour implémenter et déboguer les requêtes réseau dans des apps React Native et Expo. Elle est particulièrement utile quand vous avez besoin de plus qu’un simple prompt du type « écris-moi un appel fetch » : requêtes API, en-têtes d’authentification, choix de cache, comportement hors ligne, base URLs selon l’environnement et loaders de données avec Expo Router entrent tous dans son périmètre.

Pour quelles équipes Frontend Development c’est le plus pertinent

native-data-fetching for Frontend Development convient très bien si vous développez des fonctionnalités mobile ou Expo web qui dépendent de données distantes et que vous voulez des conventions cohérentes avec l’écosystème Expo. C’est particulièrement pertinent pour les développeurs qui hésitent entre un fetch simple, une bibliothèque de données comme React Query ou SWR, et des loaders au niveau des routes dans Expo Router.

Le vrai besoin métier couvert

Les utilisateurs cherchent généralement à faire l’une de ces quatre choses :

• livrer une intégration API fiable
• corriger un flux réseau cassé ou instable
• choisir un pattern de fetching raisonnable pour un écran ou une route
• éviter les erreurs classiques propres à Expo autour de la configuration, de l’auth et des loaders

C’est là que la skill native-data-fetching est plus utile qu’un simple survol rapide du repo : elle traite le réseau comme un choix d’implémentation, pas seulement comme un snippet de code.

Différenciateurs clés et limites

Son principal différenciateur est son alignement assumé avec Expo. La source recommande explicitement expo/fetch plutôt que axios, et va au-delà des requêtes de base pour couvrir le cache, le mode hors ligne, la gestion des tokens et les loaders d’Expo Router. Elle inclut aussi une référence ciblée sur useLoaderData et sur le modèle d’exécution server/static pour Expo web en SDK 55+.

La limite principale : il ne s’agit pas d’un framework réseau complet. C’est un document de skill avec des conseils et des exemples ; la qualité du résultat dépend donc fortement de la qualité du prompt et du degré de clarté de l’architecture de votre app.

Comment utiliser la skill native-data-fetching

Contexte d’installation de native-data-fetching

Installez la skill depuis le dépôt Expo skills :

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

Après l’installation, commencez par lire :

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

Cet ordre de lecture vous donne d’abord les principes généraux de networking, puis le modèle spécifique des loaders pour les apps web Expo Router.

Quand lancer la skill native-data-fetching

Utilisez la native-data-fetching skill dès que la tâche inclut :

• l’appel à une API externe
• l’envoi de données de formulaire ou JSON
• l’ajout d’en-têtes d’auth ou d’une logique de rafraîchissement de token
• le débogage de timeouts, d’erreurs HTTP ou de réponses mal formées
• un choix entre plain fetch, React Query, SWR ou des loaders
• la gestion du comportement hors ligne / cache
• la configuration d’URLs d’API selon l’environnement
• l’implémentation d’un chargement de données au niveau des routes avec Expo Router

Si la tâche touche à l’état réseau, au cycle de vie des requêtes ou à l’architecture des données distantes, mieux vaut l’invoquer tôt, plutôt qu’après l’apparition des bugs.

Quelles informations la skill attend de votre part

Vous obtiendrez de meilleurs résultats si vous fournissez :

• l’écran, la route ou la fonctionnalité en cours de développement
• la cible d’exécution : iOS, Android, web, ou les trois
• le type de requête : GET, POST, flux de mutation, polling, preload, etc.
• les détails API : forme de l’endpoint, modèle d’auth, réponse attendue, contrat d’erreur
• si les données doivent être mises en cache, rafraîchies, rejouées en cas d’échec ou fonctionner hors ligne
• si vous utilisez Expo Router, React Query, SWR ou le state React natif
• toute règle de configuration d’environnement ou de base URL déjà présente dans l’app

Sans ce contexte, la skill peut quand même générer du code, mais elle risque de choisir le mauvais pattern de fetching.

Transformer un objectif vague en prompt solide

Prompt faible :

Fetch user data for my screen.

Prompt plus solide :

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 version renforcée fonctionne mieux, parce qu’elle donne à la skill suffisamment d’éléments pour choisir entre une logique de fetch directe, une query library ou des patterns liés aux routes.

Choisir le bon pattern de fetching

Voici un chemin de décision pratique :

• Utilisez fetch simple ou expo/fetch pour des requêtes ponctuelles et des flux simples.
• Utilisez React Query ou SWR quand l’invalidation du cache, le rafraîchissement en arrière-plan et la déduplication des requêtes comptent.
• Utilisez les loaders d’Expo Router quand la route doit charger les données avant le rendu sur Expo web, notamment en SDK 55+.

C’est l’un des usages les plus utiles du native-data-fetching guide : lui demander de recommander un pattern avant l’implémentation.

Point d’attention sur l’usage des loaders Expo Router

La référence incluse est importante si vous utilisez useLoaderData. Les loaders dans Expo Router web ont un modèle d’exécution double :

• au chargement initial de la page, ils peuvent s’exécuter côté serveur
• lors d’une navigation côté client, le navigateur récupère les données du loader en HTTP

Cela signifie que le contexte de requête, l’hébergement et la configuration diffèrent selon les modes de sortie "server" et "static". Si votre tâche mentionne les loaders, incluez :

• la version d’Expo SDK
• le mode de sortie web
• si vous avez besoin d’accéder aux headers / cookies / à la requête
• le modèle d’hébergement

Sinon, la solution générée peut supposer des capacités que votre setup n’a pas.

Un parcours de lecture du repo qui fait gagner du temps

Pour une revue rapide de l’usage de native-data-fetching, ne parcourez pas le repo au hasard. Suivez plutôt ce chemin :

1. SKILL.md pour le périmètre et les préférences
2. references/expo-router-loaders.md si votre app utilise le chargement de données avec Expo Router
3. les fichiers de votre propre app pour le client API, les utilitaires d’auth et la configuration d’environnement

La skill upstream est assez courte ; le vrai point de friction n’est généralement pas sa lecture, mais le fait de la mapper correctement sur l’architecture actuelle de votre app.

Workflow pratique pour l’implémentation

Un bon workflow ressemble à ceci :

1. demander une recommandation de pattern
2. demander la couche de requête concrète ou le hook
3. ajouter les états d’erreur / chargement / vide
4. ajouter la gestion de l’auth et de l’environnement
5. tester les cas d’échec
6. seulement ensuite, ajouter des améliorations de cache / hors ligne si nécessaire

Cela évite de surconcevoir trop tôt. Beaucoup d’équipes partent directement sur un cache avancé avant même d’avoir validé le comportement de l’endpoint, de l’auth et de la base URL.

Préférences qui influencent le code généré

La source dit explicitement d’éviter axios et de privilégier expo/fetch. Si vous demandez quand même axios, vous allez à l’encontre de la préférence affichée par la skill. Si votre codebase standardise déjà sur axios, dites-le clairement pour que la réponse s’adapte à votre stack au lieu d’entrer en conflit avec elle.

Détails de requête à préciser dès le départ

Pour obtenir une première version exploitable, indiquez ces détails d’implémentation :

• JSON vs multipart/form-data
• headers requis
• source du token et comportement de rafraîchissement
• attentes en matière de timeout ou de retry
• si les réponses non-2xx renvoient des corps d’erreur JSON
• si l’UI doit bloquer, streamer ou afficher d’abord des données stale

Ces détails comptent souvent plus que le chemin de l’endpoint lui-même.

FAQ sur la skill native-data-fetching

Est-ce que native-data-fetching est réservé aux apps Expo ?

Elle est surtout utile dans les contextes Expo et React Native, notamment à cause de la préférence pour expo/fetch et de la référence sur les loaders d’Expo Router. Certains patterns de fetch relèvent de bonnes pratiques web générales, mais la skill est clairement pensée pour l’écosystème Expo.

Est-ce que native-data-fetching est adaptée aux débutants ?

Oui, à condition d’avoir un objectif concret. Les débutants peuvent bien utiliser la native-data-fetching skill s’ils décrivent l’écran, l’endpoint et le comportement attendu. Elle aide moins dans une démarche d’apprentissage totalement ouverte, car elle part du principe que vous êtes en train d’implémenter ou de déboguer quelque chose.

En quoi est-ce différent d’un prompt de code classique ?

Un prompt générique peut renvoyer du code fetch fonctionnel, mais passer à côté de choix propres à l’écosystème, comme la préférence pour expo/fetch, le bon modèle de chargement des données ou les particularités des loaders d’Expo Router. Le native-data-fetching guide est meilleur lorsque l’architecture et l’adéquation au framework comptent autant que la syntaxe.

Quand ne faut-il pas utiliser native-data-fetching ?

N’y recourez pas si votre tâche n’a rien à voir avec les données distantes, par exemple pour du state purement local, du styling UI, des animations ou de la navigation qui ne récupère aucune donnée. De même, si vous avez besoin d’une conception complète d’API backend ou d’un plan d’infrastructure serveur avancé, cette skill est trop ciblée.

Faut-il l’utiliser si React Query ou SWR est déjà en place ?

Oui. C’est même un très bon cas d’usage. Indiquez à la skill quelle bibliothèque vous utilisez déjà et si vous souhaitez conserver les query keys, la stratégie d’invalidation et les règles de cache existantes. Les conseils sont plus utiles lorsqu’ils prolongent votre couche de données actuelle au lieu de la remplacer.

Est-ce que native-data-fetching couvre complètement les loaders d’Expo Router ?

Elle couvre les points de décision importants pour l’adoption et renvoie vers une référence ciblée, mais pas tous les edge cases. Si les loaders sont centraux dans votre app, inspectez directement references/expo-router-loaders.md pour les détails de configuration et d’exécution avant d’implémenter un comportement de production.

Comment améliorer la skill native-data-fetching

Donner à native-data-fetching un contexte architectural, pas seulement des endpoints

Le plus gros saut de qualité vient du fait d’indiquer à la skill où la requête s’inscrit dans votre app :

• composant
• hook personnalisé
• couche de query
• route loader
• client API partagé

Cela lui permet de produire un code aligné sur votre structure, plutôt qu’un snippet isolé.

Demander des décisions avant de demander du code

Un bon pattern consiste à faire ceci :

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.

Cela réduit les retouches, car la première réponse devient une décision de conception, pas simplement du code généré.

Inclure les modes d’échec qui comptent vraiment pour vous

Si vous ne mentionnez pas la gestion des échecs, vous obtenez souvent uniquement des exemples optimistes. Pour améliorer le résultat, citez vos contraintes réelles :

• expiration de token avec 401
• appareil hors ligne
• connexions lentes
• requêtes dupliquées au focus de l’écran
• payloads JSON invalides
• erreurs 500 serveur avec message d’erreur

Ces contraintes poussent la skill vers une réponse plus proche des conditions de production.

Mode d’échec courant : hypothèses de plateforme trop floues

Beaucoup de mauvais conseils réseau viennent d’un mélange entre hypothèses web et native. Soyez explicite sur les points suivants :

• native uniquement
• web uniquement
• app universelle
• Expo Router web avec loaders
• export statique vs rendu serveur

C’est important, car le comportement des loaders, le contexte de requête et les contraintes d’hébergement changent selon ces setups.

Mode d’échec courant : gestion floue de la config et de la base URL

Si vous omettez les détails d’environnement, le code généré peut hardcoder des URLs ou placer la configuration dans la mauvaise couche. Fournissez :

• les règles de base URL pour dev / staging / prod
• si des variables d’environnement existent déjà
• où vit actuellement la configuration
• si les requêtes diffèrent selon la plateforme

Cela rend le parcours d’installation et d’adoption de native-data-fetching beaucoup plus fluide dans une app réelle.

Améliorer la qualité de sortie avec des contrats de réponse réalistes

Mieux que dire « returns user data » :

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

Cela aide la skill à générer un parsing et une gestion d’erreur plus sûrs, ce qui est particulièrement utile pour déboguer des APIs instables.

Itérer après la première réponse

Après la réponse initiale, demandez des suites comme :

• 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 première réponse doit poser le pattern ; les échanges suivants doivent ensuite l’aligner sur les contraintes réelles de votre app.

Lire la référence sur les loaders quand le rendu web compte

Si votre projet utilise un chargement de données au niveau des routes, l’amélioration la plus rapide consiste à lire references/expo-router-loaders.md, puis à formuler votre prompt avec sa terminologie : useLoaderData, "server" vs "static", accès à la requête et modèle d’hébergement. Vous obtiendrez ainsi un résultat native-data-fetching usage bien plus précis qu’avec une demande générique du type « charger les données avant le rendu ».

Garder native-data-fetching focalisée sur le travail réseau

La skill donne le meilleur d’elle-même quand le prompt reste centré sur les problématiques de données distantes. Si vous mélangez networking, gestion d’état, refonte UI et restructuration de la navigation dans une seule demande, le résultat devient généralement superficiel. Mieux vaut découper le travail pour que native-data-fetching traite d’abord proprement l’API et la couche de données.