> react-native-architecture
Feature-first project structure and separation of concerns for React Native. Use when structuring a React Native project or applying clean architecture patterns. (triggers: src/**/*.tsx, src/**/*.ts, app.json, feature, module, directory structure, separation of concerns, Expo, React Navigation, StyleSheet.create, react-native, mobile architecture)
curl "https://skillshub.wtf/HoangNguyen0403/agent-skills-standard/react-native-architecture?format=md"React Native Architecture
Priority: P0 (CRITICAL)
Feature-first organization for scalable mobile apps.
Project Structure
src/
├── features/ # Feature modules (Home, Auth, Profile)
│ └── home/
│ ├── screens/ # Screens for this feature
│ ├── components/ # Feature-specific components
│ ├── hooks/ # Feature-specific hooks
│ └── services/ # Feature-specific business logic
├── components/ # Shared components
├── navigation/ # Navigation configuration
├── services/ # Shared services (API, storage)
├── hooks/ # Shared custom hooks
├── utils/ # Utility functions
├── theme/ # Colors, typography, spacing
└── types/ # TypeScript types
Implementation Guidelines
- Feature-First: Organize by feature/module, not by type.
- Colocation: Keep related files together (screens, components, hooks within feature).
- Separation: UI (screens/components) separate from logic (hooks/services).
- Atomic Components: Reusable components in
/components. Feature-specific in feature folder. - Absolute Imports: Configure
tsconfig.jsonpaths (@/components,@/features). - Single Responsibility: Each file has one clear purpose.
- Expo vs CLI: Structure works for both. Expo uses
app.json, CLI usesindex.js.
Anti-Patterns
- No Type-Based Folders: Avoid
/containers,/screensat root. Use features. - No Logic in Screens: Extract to hooks or services.
- No Circular Deps: Features should not import from each other directly.
- No Deep Nesting: Max 3 levels deep.
Navigation Strategy
- Expo Router: Use for new projects, web-parity, and file-based routing.
- React Navigation: Use for complex deep-linking, legacy apps, or high-customization needs.
Verification Checklist (Mandatory)
- Feature-First: Is the file inside a feature directory?
- Colocation: Are hooks/services colocated with screens?
- Logic-Free Screens: Is there any business logic in the screen component?
- Navigation Choice: Does the project use the navigation strategy defined above?
References
See references/folder-structure.md for full directory tree, path mapping, and service layer patterns.
Related Topics
common/system-design | components | navigation | react/hooks | react/component-patterns
> related_skills --same-repo
> typescript-tooling
Development tools, linting, and build config for TypeScript. Use when configuring ESLint, Prettier, Jest, Vitest, tsconfig, or any TS build tooling. (triggers: tsconfig.json, .eslintrc.*, jest.config.*, package.json, eslint, prettier, jest, vitest, build, compile, lint)
> typescript-security
Secure coding practices for TypeScript. Use when validating input, handling auth tokens, sanitizing data, or managing secrets and sensitive configuration. (triggers: **/*.ts, **/*.tsx, validate, sanitize, xss, injection, auth, password, secret, token)
> typescript-language
Modern TypeScript standards for type safety and maintainability. Use when working with types, interfaces, generics, enums, unions, or tsconfig settings. (triggers: **/*.ts, **/*.tsx, tsconfig.json, type, interface, generic, enum, union, intersection, readonly, const, namespace)
> typescript-best-practices
Idiomatic TypeScript patterns for clean, maintainable code. Use when writing or refactoring TypeScript classes, functions, modules, or async logic. (triggers: **/*.ts, **/*.tsx, class, function, module, import, export, async, promise)