Install any skill in seconds. Free to start, no credit card required.
Get Started Free →React Native and Expo app patterns — Expo Router navigation, state separation (server/client/route/form), TanStack Query data fetching with Zod, performant lists, NativeWind/StyleSheet styling, native APIs, and secure storage. Use when building or editing React Native / Expo screens, components, navigation, or data layers.
.claude/skills/affaan-m-react-native-patterns/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-03 | ✗→✓ | ▲ Improved | 97% | 0% |
| case-01 | ✗→✓ | ▲ Improved | 55% | 0% |
| case-08 | ✗→✓ | ▲ Improved | 76% | 0% |
| case-22 | ✓→✗ | ▼ Worse | 430% | 0% |
| case-04 | ✓→✓ | = Same ✓ | 91% | 0% |
Practical patterns for building production React Native apps with Expo. Covers navigation, state, data fetching, lists, styling, and native APIs. Pairs with the rules/react-native/ ruleset: rules say what to enforce, this skill shows how.
Libraries named below (NativeWind, Zustand/Jotai, TanStack Query) are common, well-established options shown for illustration — the patterns matter more than the specific package, and any equivalent works. Zod is used for validation to stay consistent with ECC's existing typescript/ rules.
These patterns assume the managed Expo workflow (Expo Router, EAS, expo-* modules) on the New Architecture (the default in recent Expo SDKs, mandatory from SDK 55+). They do NOT assume the browser DOM — React Native has no <div>, no URL bar, and no web data-fetching defaults.
Use this skill when:
app/ directory)Do NOT use the web/React-DOM patterns here — URL-as-state, <div>, and SWR-for-browser do not apply to React Native.
File-based routing under app/. Keep route files thin: they read and validate params, then delegate to a screen component that lives in components/ or features/.
app/
_layout.tsx # root stack
(tabs)/
_layout.tsx # tab navigator
index.tsx # Home
user/[id].tsx # dynamic route
components/
features/
user/UserProfile.tsxDeep links and dynamic routes deliver untrusted strings. Validate them with Zod before use.
tsx// app/user/[id].tsx import { useLocalSearchParams, router } from 'expo-router' import { z } from 'zod' import { UserProfile } from '@/features/user/UserProfile' const Params = z.object({ id: z.string().uuid() }) export default function UserRoute() { const parsed = Params.safeParse(useLocalSearchParams()) if (!parsed.success) { router.replace('/not-found') return null } return <UserProfile userId={parsed.data.id} /> }
Do not duplicate server data into a client store. Each concern has its own home.
| Concern | Common choices | |---------|------| | Server state (remote data) | a server-cache library (TanStack Query, SWR) | | Client/UI state | a lightweight store (Zustand, Jotai) or Context | | Route/navigation state | Expo Router params | | Form state | a form library (e.g. React Hook Form) + schema validation | | Secrets / tokens | expo-secure-store | | Non-secret persistence | AsyncStorage / MMKV |
Prefer local useState until state genuinely needs sharing.
Use a server-cache library (TanStack Query, SWR) instead of fetch-in-useEffect. Validate at the boundary and infer types from the schema. Handle loading, error, and empty states explicitly. (Example uses TanStack Query.)
tsximport { useQuery, useMutation, useQueryClient } from '@tanstack/react-query' import { z } from 'zod' const User = z.object({ id: z.string(), email: z.string().email() }) type User = z.infer<typeof User> export function useUser(id: string) { return useQuery({ queryKey: ['user', id], queryFn: async (): Promise<User> => User.parse(await api.getUser(id)), }) } export function useUpdateEmail(id: string) { const qc = useQueryClient() return useMutation({ mutationFn: (email: string) => api.updateEmail(id, email), onSuccess: () => qc.invalidateQueries({ queryKey: ['user', id] }), }) }
tsximport { FlatList } from 'react-native' <FlatList data={items} keyExtractor={(item) => item.id} renderItem={renderItem} // memoized initialNumToRender={10} windowSize={5} />
Use FlashList (Shopify) for large or heterogeneous lists.
StyleSheet.create() is the framework-native option; utility-class libraries (e.g. NativeWind) are a common alternative. Choose one and stay consistent. Never build style objects inline in JSX on hot paths.
tsx// NativeWind <View className="p-4 rounded-2xl bg-white"> <Text className="text-base font-semibold">Hello</Text> </View> // StyleSheet const styles = StyleSheet.create({ card: { padding: 16, borderRadius: 16, backgroundColor: '#fff' } }) <View style={styles.card}>...</View>
Keep Expo SDK calls and subscriptions inside use* hooks, not in JSX. Always clean up.
tsximport { useEffect, useState } from 'react' import * as Location from 'expo-location' type LocationState = | { status: 'loading' } | { status: 'denied' } | { status: 'granted'; coords: Location.LocationObjectCoords } export function useCurrentLocation() { // Track status, not just coords — so the UI can tell "still loading" apart // from "permission denied" and show an actionable message. const [state, setState] = useState<LocationState>({ status: 'loading' }) useEffect(() => { let active = true ;(async () => { const { status } = await Location.requestForegroundPermissionsAsync() if (status !== 'granted') { if (active) setState({ status: 'denied' }) return } const pos = await Location.getCurrentPositionAsync({}) if (active) setState({ status: 'granted', coords: pos.coords }) })() return () => { active = false } // ignore stale result after unmount }, []) return state }
tsximport * as SecureStore from 'expo-secure-store' await SecureStore.setItemAsync('auth_token', token) // Keychain / Keystore const token = await SecureStore.getItemAsync('auth_token')
tsx// app/(tabs)/orders.tsx import { memo, useCallback } from 'react' import { FlatList, Text, View } from 'react-native' import { useQuery } from '@tanstack/react-query' import { z } from 'zod' const OrderSchema = z.object({ id: z.string(), total: z.number(), status: z.string() }) const OrdersSchema = z.array(OrderSchema) type Order = z.infer<typeof OrderSchema> function useOrders() { return useQuery({ queryKey: ['orders'], queryFn: async () => OrdersSchema.parse(await api.listOrders()), }) } // Memoized so its reference is stable across renders (see the lists guidance). const OrderRow = memo(function OrderRow({ item }: { item: Order }) { return ( <View className="px-4 py-3 border-b border-neutral-200"> <Text className="font-medium">#{item.id}</Text> <Text className="text-neutral-500">{item.status} · ${item.total}</Text> </View> ) }) export default function OrdersScreen() { const { data, isLoading, isError, refetch, isRefetching } = useOrders() const renderItem = useCallback(({ item }: { item: Order }) => <OrderRow item={item} />, []) if (isLoading) return <Centered><Text>Loading…</Text></Centered> if (isError) return <Centered><Text accessibilityRole="alert">Could not load orders.</Text></Centered> if (!data?.length) return <Centered><Text>No orders yet.</Text></Centered> return ( <FlatList data={data} keyExtractor={(o) => o.id} onRefresh={refetch} refreshing={isRefetching} renderItem={renderItem} /> ) }
tsximport { useForm, Controller } from 'react-hook-form' import { zodResolver } from '@hookform/resolvers/zod' import { z } from 'zod' import { TextInput, Button, Text } from 'react-native' const Schema = z.object({ email: z.string().email('Invalid email') }) type FormValues = z.infer<typeof Schema> export function EmailForm({ onSubmit }: { onSubmit: (v: FormValues) => void }) { const { control, handleSubmit, formState: { errors } } = useForm<FormValues>({ resolver: zodResolver(Schema), defaultValues: { email: '' }, }) return ( <> <Controller control={control} name="email" render={({ field: { value, onChange, onBlur } }) => ( <TextInput value={value} onChangeText={onChange} onBlur={onBlur} autoCapitalize="none" keyboardType="email-address" accessibilityLabel="Email address" /> )} /> {errors.email && <Text accessibilityRole="alert">{errors.email.message}</Text>} <Button title="Save" onPress={handleSubmit(onSubmit)} /> </> ) }
tsx// WRONG: large array mapped inside a ScrollView (no virtualization, janky, high memory) <ScrollView>{items.map((i) => <Row key={i.id} item={i} />)}</ScrollView> // RIGHT: FlatList / FlashList // WRONG: server data copied into a client store (two sources of truth, stale data) const useStore = create((set) => ({ users: [], setUsers: (u) => set({ users: u }) })) useEffect(() => { getUsers().then(setUsers) }, []) // RIGHT: useQuery owns server state; derive what you need // WRONG: tokens in AsyncStorage (not encrypted) await AsyncStorage.setItem('auth_token', token) // RIGHT: expo-secure-store // WRONG: trusting deep-link params const { id } = useLocalSearchParams(); fetchUser(id) // RIGHT: validate with Zod before use // WRONG: inline style object recreated every render on a hot path <View style={{ padding: 16, backgroundColor: '#fff' }} /> // RIGHT: StyleSheet.create at module scope, or NativeWind className // WRONG: real secret shipped in the bundle const STRIPE_SECRET = 'sk_live_...' // RIGHT: keep privileged calls server-side; ship only public keys protected by backend rules
use* hooks.renderItem; provide a stable keyExtractor.react-native-reanimated for animation (UI thread); avoid heavy work on the JS thread.expo-secure-store; never trust the client for authorization.frontend-patterns — React/Next.js (web) patterns; useful for shared React concepts, but DOM-specific.coding-standards — TypeScript/JavaScript idioms that apply to RN code.tdd-workflow, e2e-testing — testing process (use Jest + React Native Testing Library, Maestro/Detox for RN).security-review — general security checklist that complements the RN bundle/secret guidance above.| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-02 | fail→fail | 15,372 | 11,095 | -28% | 1 | 1 | 0% | 3,218 | 5,216 | +62% | 0 | 0 | — |
case-03 | fail→pass | 16,859 | 20,118 | +19% | 1 | 1 | 0% | 3,951 | 7,779 | +97% | 0 | 0 | — |
case-01 | fail→pass | 16,170 | 12,745 | -21% | 1 | 1 | 0% | 3,833 | 5,931 | +55% | 0 | 0 | — |
case-04 | pass→pass | 11,540 | 9,867 | -14% | 1 | 1 | 0% | 2,630 | 5,031 | +91% | 0 | 0 | — |
case-05 | pass→pass | 14,427 | 10,743 | -26% | 1 | 1 | 0% | 2,969 | 5,126 | +73% | 0 | 0 | — |
case-06 | pass→pass | 10,613 | 5,471 | -48% | 1 | 1 | 0% | 2,030 | 3,938 | +94% | 0 | 0 | — |
case-07 | pass→pass | 14,108 | 10,312 | -27% | 1 | 1 | 0% | 2,694 | 5,058 | +88% | 0 | 0 | — |
case-08 | fail→pass | 13,518 | 9,027 | -33% | 1 | 1 | 0% | 2,862 | 5,049 | +76% | 0 | 0 | — |
case-09 | pass→pass | 12,200 | 5,771 | -53% | 1 | 1 | 0% | 2,337 | 4,064 | +74% | 0 | 0 | — |
case-10 | pass→pass | 16,562 | 13,538 | -18% | 1 | 1 | 0% | 3,657 | 5,993 | +64% | 0 | 0 | — |
case-11 | pass→pass | 13,120 | 9,806 | -25% | 1 | 1 | 0% | 2,602 | 4,928 | +89% | 0 | 0 | — |
case-12 | pass→pass | 12,397 | 10,896 | -12% | 1 | 1 | 0% | 2,544 | 5,097 | +100% | 0 | 0 | — |
case-13 | pass→pass | 11,537 | 10,335 | -10% | 1 | 1 | 0% | 2,456 | 5,217 | +112% | 0 | 0 | — |
case-14 | fail→fail | 11,937 | 10,330 | -13% | 1 | 1 | 0% | 2,267 | 4,316 | +90% | 0 | 0 | — |
case-15 | pass→pass | 13,481 | 7,865 | -42% | 1 | 1 | 0% | 2,213 | 4,494 | +103% | 0 | 0 | — |
case-16 | pass→pass | 12,358 | 5,849 | -53% | 1 | 1 | 0% | 2,204 | 4,168 | +89% | 0 | 0 | — |
case-17 | pass→pass | 16,125 | 9,008 | -44% | 1 | 1 | 0% | 2,912 | 4,697 | +61% | 0 | 0 | — |
case-18 | pass→pass | 9,604 | 7,068 | -26% | 1 | 1 | 0% | 1,914 | 4,381 | +129% | 0 | 0 | — |
case-19 | pass→pass | 14,388 | 9,715 | -32% | 1 | 1 | 0% | 2,735 | 4,940 | +81% | 0 | 0 | — |
case-20 | pass→pass | 14,495 | 11,858 | -18% | 1 | 1 | 0% | 2,708 | 5,319 | +96% | 0 | 0 | — |
case-21 | pass→pass | 11,170 | 11,317 | +1% | 1 | 1 | 0% | 2,393 | 5,040 | +111% | 0 | 0 | — |
case-22 | pass→fail | 3,615 | 3,925 | +9% | 1 | 1 | 0% | 689 | 3,650 | +430% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted. The headline lift of +9 percentage points is the difference between those two pass rates over the 22 comparable cases. 1 case got worse with the skill loaded, and it is included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.