native-data-fetching

Überblick über den Skill native-data-fetching

Wobei native-data-fetching tatsächlich hilft

Der Skill native-data-fetching ist ein Expo-fokussierter Leitfaden für die Implementierung und das Debugging von Netzwerk-Requests in React-Native- und Expo-Apps. Besonders nützlich ist er dann, wenn ein generischer Prompt wie „schreib mir einen fetch call“ nicht ausreicht: API-Requests, Auth-Header, Caching-Entscheidungen, Offline-Verhalten, umgebungsspezifische Base-URLs und Daten-Loader in Expo Router gehören hier ausdrücklich zum Einsatzbereich.

Beste Eignung für Frontend-Development-Teams

native-data-fetching for Frontend Development passt besonders gut, wenn ihr Mobile- oder Expo-Web-Features entwickelt, die von Remote-Daten abhängen, und dabei Konventionen nutzen wollt, die zur Expo-Welt passen. Besonders relevant ist der Skill für Entwickler:innen, die zwischen einfachem fetch, einer Datenbibliothek wie React Query oder SWR und routebasierten Loadern in Expo Router entscheiden müssen.

Der konkrete Job-to-be-done

Nutzer:innen versuchen in der Regel eines von vier Dingen:

• eine zuverlässige API-Integration auszuliefern
• einen kaputten oder instabilen Netzwerk-Flow zu reparieren
• ein sinnvolles Fetching-Muster für einen Screen oder eine Route auszuwählen
• typische Expo-spezifische Fehler bei Konfiguration, Auth und Loadern zu vermeiden

Genau hier ist der Skill native-data-fetching hilfreicher als ein oberflächlicher Repo-Überblick: Er behandelt Networking als Implementierungsentscheidung und nicht bloß als Codeschnipsel.

Zentrale Unterschiede und Grenzen

Der wichtigste Unterschied ist die klare Ausrichtung auf Expo. Die Quelle bevorzugt ausdrücklich expo/fetch gegenüber axios und geht deutlich über einfache Requests hinaus — etwa bei Caching, Offline-Support, Token-Handling und Expo-Router-Loadern. Außerdem gibt es eine fokussierte Referenz zu useLoaderData sowie zum Server-/Static-Ausführungsmodell für Expo Web in SDK 55+.

Die wichtigste Einschränkung: Das ist kein vollständiges Networking-Framework. Es handelt sich um ein Skill-Dokument mit Empfehlungen und Beispielen. Die Qualität der Ergebnisse hängt daher stark von der Qualität des Prompts ab und davon, ob die Architektur eurer App bereits klar ist.

So verwendest du den Skill native-data-fetching

Installationskontext für native-data-fetching

Installiere den Skill aus dem Expo-Skills-Repository:

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

Nach der Installation solltest du zuerst diese Dateien lesen:

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

Diese Reihenfolge ist sinnvoll: erst die allgemeinen Networking-Empfehlungen, dann das Sondermodell für Loader in Expo-Router-Web-Apps.

Wann du native-data-fetching einsetzen solltest

Nutze den native-data-fetching skill immer dann, wenn die Aufgabe Folgendes umfasst:

• eine externe API aufzurufen
• Formular- oder JSON-Daten zu senden
• Auth-Header oder Token-Refresh-Logik hinzuzufügen
• Timeouts, HTTP-Fehler oder fehlerhafte Responses zu debuggen
• zwischen plain fetch, React Query, SWR oder Loadern zu wählen
• Offline-/Cache-Verhalten zu behandeln
• API-URLs abhängig von der Umgebung zu konfigurieren
• routebasiertes Datenladen mit Expo Router umzusetzen

Wenn die Aufgabe Netzwerkzustand, Request-Lifecycles oder die Architektur für Remote-Daten berührt, solltest du den Skill früh einsetzen — nicht erst dann, wenn bereits Bugs aufgetreten sind.

Welche Eingaben der Skill von dir braucht

Du bekommst bessere Ergebnisse, wenn du Folgendes mitlieferst:

• den Screen, die Route oder das Feature, das gebaut wird
• das Ziel-Runtime-Umfeld: iOS, Android, Web oder alle drei
• den Request-Typ: GET, POST, Mutation-Flow, Polling, Preload usw.
• API-Details: Endpoint-Struktur, Auth-Modell, erwartete Response, Fehlervertrag
• ob Daten gecacht, aktualisiert, erneut versucht oder offline verfügbar sein müssen
• ob du Expo Router, React Query, SWR oder plain React state verwendest
• welche Umgebungs-Konfiguration oder Base-URL-Regeln in der App bereits existieren

Ohne diesen Kontext kann der Skill zwar weiterhin Code generieren, wählt aber möglicherweise das falsche Fetching-Muster.

Aus einem groben Ziel einen starken Prompt machen

Schwacher Prompt:

Fetch user data for my screen.

Stärkerer Prompt:

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.

Die stärkere Variante funktioniert besser, weil sie dem Skill genug Informationen gibt, um zwischen direkter Fetch-Logik, einer Query-Bibliothek und routebewussten Mustern zu unterscheiden.

Das richtige Fetching-Muster wählen

Ein praktikabler Entscheidungsweg:

• Nutze plain fetch oder expo/fetch für einmalige Requests und einfache Flows.
• Nutze React Query oder SWR, wenn Cache-Invalidierung, Hintergrund-Refresh und Request-Deduplizierung wichtig sind.
• Nutze Expo-Router-Loader, wenn eine Route Daten vor dem Rendern in Expo Web laden soll, besonders ab SDK 55+.

Das ist einer der wertvollsten Einsatzzwecke des native-data-fetching guide: sich vor der Implementierung ein Muster empfehlen zu lassen.

Wichtiger Hinweis zur Nutzung von Expo Router Loadern

Die enthaltene Referenz ist relevant, wenn du useLoaderData verwendest. Loader in Expo Router Web folgen einem zweigleisigen Ausführungsmodell:

• beim initialen Seitenaufruf können sie serverseitig laufen
• bei clientseitiger Navigation lädt der Browser die Loader-Daten per HTTP

Das bedeutet, dass sich Request-Kontext, Hosting und Konfiguration je nach Output-Modus "server" oder "static" unterscheiden. Wenn deine Aufgabe Loader betrifft, gib deshalb Folgendes an:

• Expo-SDK-Version
• Web-Output-Modus
• ob du Header/Cookies/Request-Zugriff brauchst
• Hosting-Modell

Andernfalls kann die generierte Lösung Fähigkeiten voraussetzen, die dein Setup gar nicht unterstützt.

Repo-Lesepfad, der Zeit spart

Für einen schnellen Überblick zur native-data-fetching usage solltest du das Repo nicht zufällig durchsuchen. Nutze stattdessen diesen Pfad:

1. SKILL.md für Scope und Präferenzen
2. references/expo-router-loaders.md, falls deine App Expo-Router-Datenladen nutzt
3. den API-Client, die Auth-Utilities und die Environment-Config-Dateien deiner eigenen App

Der Upstream-Skill ist kurz genug; der Engpass liegt meist nicht im Lesen, sondern darin, ihn korrekt auf die aktuelle App-Architektur zu übertragen.

Praktischer Workflow für die Implementierung

Ein sinnvoller Workflow ist:

1. zuerst eine Muster-Empfehlung einholen
2. dann nach der konkreten Request-Schicht oder einem Hook fragen
3. Error-, Loading- und Empty-States ergänzen
4. Auth- und Environment-Handling hinzufügen
5. Fehlerfälle testen
6. erst danach bei Bedarf Cache-/Offline-Verbesserungen ergänzen

So vermeidest du Overengineering. Viele Teams springen direkt zu fortgeschrittenem Caching, bevor überhaupt klar ist, ob Endpoint, Auth und Base-URL-Verhalten sauber funktionieren.

Präferenzen, die den generierten Code beeinflussen

Die Quelle sagt ausdrücklich, dass axios vermieden und expo/fetch bevorzugt werden soll. Wenn du trotzdem nach axios fragst, arbeitest du gegen die ausdrückliche Präferenz des Skills. Wenn eure Codebasis bereits auf axios standardisiert ist, erwähne das klar, damit sich die Ausgabe anpassen kann, statt gegen euren Stack zu arbeiten.

Typische Request-Details, die du früh angeben solltest

Damit der erste Entwurf direkt brauchbar ist, solltest du diese Implementierungsdetails nennen:

• JSON vs multipart/form-data
• erforderliche Header
• Token-Quelle und Refresh-Verhalten
• Timeout- oder Retry-Erwartungen
• ob Nicht-2xx-Responses JSON-Fehler-Bodies zurückgeben
• ob die UI blockieren, streamen oder zunächst veraltete Daten rendern soll

Diese Details sind oft wichtiger als der Endpoint-Pfad selbst.

FAQ zum Skill native-data-fetching

Ist native-data-fetching nur für Expo-Apps gedacht?

Seinen größten Nutzen hat der Skill im Expo- und React-Native-Kontext, besonders wegen der Präferenz für expo/fetch und der Referenz zu Expo-Router-Loadern. Einige Fetch-Muster sind allgemeines Web-Wissen, aber der Skill ist klar auf das Expo-Ökosystem zugeschnitten.

Ist native-data-fetching anfängerfreundlich?

Ja — wenn dein Ziel konkret ist. Einsteiger:innen können den native-data-fetching skill gut nutzen, wenn sie Screen, Endpoint und erwartetes Verhalten beschreiben. Für völlig offenes Lernen ist er weniger geeignet, weil er davon ausgeht, dass du aktiv etwas implementierst oder debuggst.

Worin unterscheidet sich das von einem normalen Coding-Prompt?

Ein generischer Prompt kann funktionierenden Fetch-Code liefern, dabei aber ecosystem-spezifische Entscheidungen übersehen — zum Beispiel die Präferenz für expo/fetch, das passende Datenlade-Modell oder das Verhalten von Expo-Router-Loadern. Der native-data-fetching guide ist besser geeignet, wenn Architektur und Framework-Fit genauso wichtig sind wie Syntax.

Wann sollte ich native-data-fetching nicht verwenden?

Greife nicht dazu, wenn deine Aufgabe nichts mit Remote-Daten zu tun hat — etwa bei rein lokalem State, UI-Styling, Animationen oder Navigation ohne Datenabruf. Und wenn du ein vollständiges Backend-API-Design oder einen fortgeschrittenen Infrastrukturplan für Server brauchst, ist dieser Skill zu eng gefasst.

Sollte ich den Skill nutzen, wenn React Query oder SWR bereits im Einsatz sind?

Ja. Tatsächlich ist das ein besonders starker Anwendungsfall. Teile dem Skill mit, welche Bibliothek ihr bereits nutzt und ob bestehende Query-Keys, Invalidierungsstrategie und Cache-Regeln erhalten bleiben sollen. Die Empfehlungen sind deutlich nützlicher, wenn sie eure bestehende Datenebene erweitern statt sie zu ersetzen.

Deckt native-data-fetching Expo Router Loader vollständig ab?

Er deckt die wichtigen Entscheidungsstellen für die Einführung ab und verlinkt auf eine fokussierte Referenz, aber nicht jeden Edge Case. Wenn Loader zentral für deine App sind, solltest du references/expo-router-loaders.md direkt auf Konfigurations- und Ausführungsdetails prüfen, bevor du produktionsrelevantes Verhalten umsetzt.

So verbesserst du den Skill native-data-fetching

Gib native-data-fetching Architekturkontext, nicht nur Endpoints

Der größte Qualitätssprung entsteht, wenn du dem Skill sagst, wo der Request in deiner App lebt:

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

So kann er Code erzeugen, der zu deiner Struktur passt, statt nur ein losgelöstes Snippet zu liefern.

Frage erst nach Entscheidungen, dann nach Code

Ein starkes Muster ist:

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.

Das reduziert Nacharbeit, weil die erste Antwort dann eine Designentscheidung liefert und nicht nur generierten Code.

Nenne die Failure-Modes, die dich wirklich interessieren

Wenn du Fehlerbehandlung nicht erwähnst, bekommst du oft nur optimistische Beispiele. Bessere Ergebnisse erhältst du, wenn du reale Risiken benennst:

• 401 token expiry
• offline device
• slow connections
• duplicate requests on screen focus
• bad JSON payloads
• server 500s with error messages

Diese Randbedingungen lenken den Skill stärker in Richtung produktionsreifer Ergebnisse.

Häufiger Fehler: vage Plattformannahmen

Viel schlechter Networking-Rat entsteht dadurch, dass native und Web-Annahmen vermischt werden. Sei deshalb klar bei Angaben wie:

• native only
• web only
• universal app
• Expo Router web with loaders
• static export vs server rendering

Das ist wichtig, weil sich Loader-Verhalten, Request-Kontext und Hosting-Einschränkungen je nach Setup ändern.

Häufiger Fehler: unklare Config- und Base-URL-Behandlung

Wenn du Umgebungsdetails weglässt, kann generierter Code URLs hart codieren oder Config in der falschen Schicht ablegen. Gib deshalb an:

• Regeln für Base-URLs in dev/staging/prod
• ob Env-Variablen bereits existieren
• wo Config aktuell liegt
• ob Requests sich je nach Plattform unterscheiden

So wird der native-data-fetching install- und Einführungsweg in einer echten App deutlich reibungsloser.

Verbessere die Ausgabequalität mit realistischen Response-Verträgen

Besser als nur „returns user data“ ist zum Beispiel:

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

Das hilft dem Skill, robusteres Parsing und bessere Fehlerbehandlung zu generieren — besonders nützlich beim Debugging instabiler APIs.

Nach der ersten Antwort weiter iterieren

Nach der ersten Ausgabe kannst du mit Follow-ups wie diesen weiterarbeiten:

• 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

Die erste Antwort sollte das Muster festlegen; spätere Turns sollten es an die realen Randbedingungen deiner App anpassen.

Lies die Loader-Referenz, wenn Web-Rendering wichtig ist

Wenn dein Projekt routebasiertes Datenladen nutzt, ist die schnellste Verbesserung, references/expo-router-loaders.md zu lesen und dann mit dessen Begriffen zu prompten: useLoaderData, "server" vs "static", Request-Zugriff und Hosting-Modell. Das liefert deutlich schärfere Ergebnisse für die native-data-fetching usage als eine allgemeine Anfrage wie „load data before render“.

Halte native-data-fetching auf Networking-Arbeit fokussiert

Der Skill funktioniert am besten, wenn der Prompt auf Remote-Daten fokussiert bleibt. Wenn du Networking, State-Management, UI-Redesign und Navigation-Restrukturierung in einer einzigen Anfrage vermischst, wird das Ergebnis meist oberflächlich. Teile die Arbeit auf, damit native-data-fetching zuerst API- und Datenebene sauber abdeckt.