rn-async-patterns
Async/await correctness in React Native with Zustand. Use when debugging race conditions, missing awaits, floating promises, or async timing issues in Expo/React Native apps.
Best use case
rn-async-patterns is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Async/await correctness in React Native with Zustand. Use when debugging race conditions, missing awaits, floating promises, or async timing issues in Expo/React Native apps.
Teams using rn-async-patterns should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/rn-async-patterns/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How rn-async-patterns Compares
| Feature / Agent | rn-async-patterns | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Async/await correctness in React Native with Zustand. Use when debugging race conditions, missing awaits, floating promises, or async timing issues in Expo/React Native apps.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# React Native Async Patterns
## Problem Statement
Async bugs in React Native are insidious because they often work in development but fail under load or on slower devices. The most common issues: missing `await` on async functions, race conditions between state updates, and assuming operations complete in order.
---
## Pattern: Floating Promise Detection
**Problem:** Calling an async function without `await` causes it to run in the background. If subsequent code depends on its completion, you get a race condition.
**Example (from retake bug):**
```typescript
// Before (buggy) - enableSkillAreaRetake is async but not awaited
enableSkillAreaRetake(skillArea); // Fire and forget ❌
await clearSkillAreaAnswers(skillArea); // Runs before enable completes
// After (fixed)
await enableSkillAreaRetake(skillArea); // Wait for state update ✅
await clearSkillAreaAnswers(skillArea); // Now runs in correct order
```
**Why it's subtle:** Both functions might have `async` in their signature, but only one was awaited. The code "looks right" at a glance.
**Detection:**
```bash
# Find potential floating promises - async calls without await
grep -rn "^\s*[a-zA-Z]*\s*(" --include="*.ts" --include="*.tsx" | \
grep -v "await\|return\|const\|let\|if\|else\|=>"
```
**Prevention:**
1. ESLint rule `@typescript-eslint/no-floating-promises` - catches this at lint time
2. Code review trigger: Any line calling a function that might be async without `await`, `return`, or assignment
---
## Pattern: Post-Condition Validation
**Problem:** Assuming an async call succeeded without verifying. The call might return early, throw silently, or fail to update state.
**Example (from retake bug):**
```typescript
// Before (buggy) - assumed load worked
await loadCompletedAssessmentAnswers(id);
// Proceeded blindly with retake flow...
// After (defensive)
await loadCompletedAssessmentAnswers(id);
const loaded = useAssessmentStore.getState().completedAssessmentAnswers;
if (Object.keys(loaded).length === 0) {
throw new Error(
`Failed to load answers for assessment ${id} - cannot proceed with retake`
);
}
```
**Principle:** Treat every async call as potentially failed until proven otherwise.
**When to validate:**
- After loading data that subsequent operations depend on
- After state updates that must complete before continuing
- Before irreversible operations (submissions, deletions)
**Pattern template:**
```typescript
await someAsyncOperation();
const result = getRelevantState();
if (!isValid(result)) {
throw new Error(`[${functionName}] Post-condition failed: ${diagnosticContext}`);
}
```
---
## Pattern: Async Function Identification
**Problem:** Not all async functions look async. Zustand actions, callbacks, and promise-returning functions may not have obvious `async` keywords.
**Hidden async patterns:**
```typescript
// Obvious async
async function fetchData() { ... }
// Less obvious - returns Promise
function fetchData(): Promise<Data> { ... }
// Hidden - Zustand action that's actually async
const useStore = create((set, get) => ({
// This looks sync but calls async internally
enableRetake: (area: string) => {
someAsyncSetup().then(() => { // ← Hidden async!
set({ retakeAreas: [...get().retakeAreas, area] });
});
},
}));
// Proper async Zustand action
const useStore = create((set, get) => ({
enableRetake: async (area: string) => {
await someAsyncSetup();
set({ retakeAreas: [...get().retakeAreas, area] });
},
}));
```
**Detection:** Check function signatures and implementations:
```bash
# Find functions returning Promise
grep -rn "): Promise<" --include="*.ts" --include="*.tsx"
# Find .then() chains that might need await
grep -rn "\.then(" --include="*.ts" --include="*.tsx"
```
---
## Pattern: Sequential vs Parallel Async
**Problem:** Running async operations sequentially when they could be parallel (slow), or parallel when they must be sequential (race condition).
```typescript
// Sequential - correct when order matters
await enableSkillAreaRetake(skillArea);
await clearSkillAreaAnswers(skillArea);
await loadRetakeQuestions(skillArea);
// Parallel - correct when operations are independent
const [user, settings, history] = await Promise.all([
fetchUser(id),
fetchSettings(id),
fetchHistory(id),
]);
// WRONG - parallel when order matters
await Promise.all([
enableSkillAreaRetake(skillArea), // These have dependencies!
clearSkillAreaAnswers(skillArea),
]);
```
**Decision framework:**
| Operations share state? | Must run in order? | Pattern |
|------------------------|-------------------|---------|
| No | No | `Promise.all()` |
| Yes | Yes | Sequential `await` |
| Yes | No | Usually sequential to be safe |
---
## Pattern: Async in useEffect
**Problem:** `useEffect` callbacks can't be async directly. Common mistakes with cleanup and race conditions.
```typescript
// WRONG - useEffect can't be async
useEffect(async () => {
const data = await fetchData();
setData(data);
}, []);
// CORRECT - async function inside
useEffect(() => {
async function load() {
const data = await fetchData();
setData(data);
}
load();
}, []);
// BETTER - with cleanup for race conditions
useEffect(() => {
let cancelled = false;
async function load() {
const data = await fetchData();
if (!cancelled) {
setData(data);
}
}
load();
return () => {
cancelled = true;
};
}, [dependency]);
```
---
## ESLint Configuration
Apply config from `configs/eslint-async.json` to catch these issues at lint time:
```json
{
"rules": {
"@typescript-eslint/no-floating-promises": "error",
"@typescript-eslint/require-await": "warn",
"@typescript-eslint/await-thenable": "error",
"@typescript-eslint/no-misused-promises": "error"
}
}
```
**Required:** `@typescript-eslint/eslint-plugin` and proper TypeScript configuration.
---
## Code Review Checklist
When reviewing async code, check:
- [ ] Every async function call is either `await`ed, `return`ed, or explicitly fire-and-forget with comment
- [ ] Operations that depend on each other are sequenced with `await`
- [ ] Post-conditions validated after critical async operations
- [ ] `useEffect` with async uses the inner function pattern
- [ ] Race conditions considered when component could unmount during async
- [ ] Error handling exists for async failures
---
## Quick Debugging
When async timing issues occur:
```typescript
// Add timestamps to trace execution order
console.log(`[${Date.now()}] Starting enableRetake`);
await enableSkillAreaRetake(skillArea);
console.log(`[${Date.now()}] Finished enableRetake`);
console.log(`[${Date.now()}] Starting clearAnswers`);
await clearSkillAreaAnswers(skillArea);
console.log(`[${Date.now()}] Finished clearAnswers`);
```
Look for:
- Operations finishing out of expected order
- Operations starting before previous ones complete
- Suspiciously fast "completions" (might not have awaited)Related Skills
coderabbit-sdk-patterns
Apply production-ready CodeRabbit automation patterns using GitHub API and PR comments. Use when building automation around CodeRabbit reviews, processing review feedback programmatically, or integrating CodeRabbit into custom workflows. Trigger with phrases like "coderabbit automation", "coderabbit API patterns", "automate coderabbit", "coderabbit github api", "process coderabbit reviews".
clickup-sdk-patterns
Production-ready ClickUp API v2 client patterns with typed wrappers, error handling, caching, and multi-tenant support. Trigger: "clickup client wrapper", "clickup SDK patterns", "clickup best practices", "clickup typescript client", "clickup API wrapper", "production clickup code".
clickhouse-sdk-patterns
Production-ready patterns for @clickhouse/client — streaming inserts, typed queries, error handling, and connection management. Use when building robust ClickHouse integrations, implementing streaming, or establishing team coding standards. Trigger: "clickhouse SDK patterns", "clickhouse client patterns", "clickhouse best practices", "clickhouse streaming insert".
clerk-sdk-patterns
Common Clerk SDK patterns and best practices. Use when implementing authentication flows, accessing user data, or integrating Clerk SDK methods in your application. Trigger with phrases like "clerk SDK", "clerk patterns", "clerk best practices", "clerk API usage".
clay-sdk-patterns
Apply production-ready patterns for integrating with Clay via webhooks and HTTP API. Use when building Clay integrations, implementing webhook handlers, or establishing team coding standards for Clay data pipelines. Trigger with phrases like "clay SDK patterns", "clay best practices", "clay code patterns", "clay integration patterns", "clay webhook patterns".
clay-reliability-patterns
Build fault-tolerant Clay integrations with circuit breakers, dead letter queues, and graceful degradation. Use when building production Clay pipelines that need resilience, implementing retry strategies, or adding fault tolerance to enrichment workflows. Trigger with phrases like "clay reliability", "clay circuit breaker", "clay resilience", "clay fallback", "clay fault tolerance", "clay dead letter queue".
clari-sdk-patterns
Production-ready Clari API client patterns in Python and TypeScript. Use when building reusable Clari clients, implementing export pipelines, or wrapping the Clari v4 API for team use. Trigger with phrases like "clari API patterns", "clari client wrapper", "clari Python client", "clari TypeScript client".
clade-sdk-patterns
Production-ready Anthropic SDK patterns — client config, retries, timeouts, Use when working with sdk-patterns patterns. error handling, TypeScript types, and async patterns. Trigger with "anthropic sdk", "claude client setup", "anthropic typescript", "anthropic python patterns".
clade-reliability-patterns
Build fault-tolerant Claude integrations — retries, circuit breakers, Use when working with reliability-patterns patterns. fallbacks, timeouts, and graceful degradation. Trigger with "anthropic reliability", "claude fault tolerance", "anthropic circuit breaker", "claude fallback".
castai-sdk-patterns
Production-ready CAST AI REST API wrapper patterns in TypeScript and Python. Use when building reusable CAST AI clients, implementing retry logic, or wrapping the CAST AI API for team use. Trigger with phrases like "cast ai API patterns", "cast ai client wrapper", "cast ai TypeScript", "cast ai Python client".
canva-sdk-patterns
Apply production-ready Canva Connect API client patterns for TypeScript and Python. Use when building a reusable API client, implementing token refresh, or establishing team coding standards for Canva integrations. Trigger with phrases like "canva client patterns", "canva best practices", "canva code patterns", "canva API wrapper", "canva TypeScript client".
canva-reliability-patterns
Implement reliability patterns for Canva Connect API — circuit breakers, idempotency, graceful degradation. Use when building fault-tolerant Canva integrations, implementing retry strategies, or adding resilience to production Canva services. Trigger with phrases like "canva reliability", "canva circuit breaker", "canva resilience", "canva fallback", "canva fault tolerance".