home / skills / busirocket / agents-skills / busirocket-react-components-and-hooks

busirocket-react-components-and-hooks skill

safe

/skills/busirocket-react-components-and-hooks

This skill enforces a strict React structure with one component per file and one hook per hook file to improve maintainability and reuse.

npx playbooks add skill busirocket/agents-skills --skill busirocket-react-components-and-hooks

Review the files below or copy the command above to add this skill to your agents.

Files (11)

SKILL.md

2.0 KB

---
name: busirocket-react-components-and-hooks
description:
  React component and hook structure rules. Use when writing or refactoring
  React components, extracting hooks, deciding client vs server components, and
  enforcing one-component/one-hook per file with no helpers or inline types.
metadata:
  author: cristiandeluxe
  version: "1.0.0"
---

# React Components and Hooks

Reusable patterns for scalable React codebases.

## When to Use

Use this skill when:

- Writing or refactoring `.tsx` components
- Extracting hooks into `hooks/<area>/useXxx.ts`
- Removing helpers from components/hooks into `utils/`
- Removing inline types into `types/`

## Non-Negotiables (MUST)

- Exactly **one exported component per `.tsx` file**.
- Exactly **one exported hook per hook file** (`hooks/<area>/useXxx.ts`).
- **No helper functions inside** components or hooks; extract helpers to
  `utils/`.
- **No inline types** inside components or hooks; import from `types/`.
- Prefer server-side rendering boundaries wisely (avoid `'use client'` for large
  subtrees).

## Rules

### Component Patterns

- `react-one-component-per-file` - One component per file (STRICT)
- `react-client-vs-server` - Client vs Server Components (App Router)
- `react-folder-namespacing` - Folder namespacing for complex components
- `react-performance` - Performance optimization (memo, useCallback)
- `react-accessibility` - Accessibility best practices

### Hooks Best Practices

- `react-one-hook-per-file` - One hook per file (STRICT)
- `react-no-helpers-in-hooks` - No helpers inside hooks (STRICT)
- `react-no-types-in-hooks` - No types inside hooks (STRICT)
- `react-stable-api` - Stable API for hooks
- `react-side-effects` - Side effects in hooks

## How to Use

Read individual rule files for detailed explanations and code examples:

```
rules/react-one-component-per-file.md
rules/react-one-hook-per-file.md
rules/react-client-vs-server.md
```

Each rule file contains:

- Brief explanation of why it matters
- Code examples (correct and incorrect patterns)
- Additional context and best practices

Overview

This skill enforces consistent React component and hook structure for TypeScript/React/Next.js projects. It codifies one-component-per-file and one-hook-per-file rules, moves helpers and inline types into dedicated folders, and helps teams decide client vs server components. Use it to make code easier to test, review, and scale.

How this skill works

The skill inspects .tsx component files, hook files under hooks/, and common folders like utils/ and types/. It flags violations: multiple exports in one file, helpers or inline types inside components or hooks, and improper client/server boundaries. It also suggests extracting helpers to utils/, types to types/, and hooks to hooks/<area>/useXxx.ts.

When to use it

Writing new .tsx components
Refactoring large components into smaller parts
Extracting or creating reusable hooks
Enforcing codebase-wide structure rules
Auditing client vs server component boundaries

Best practices

Keep exactly one exported React component per .tsx file.
Keep exactly one exported hook per hook file (hooks/<area>/useXxx.ts).
Move helper functions from components/hooks into utils/ and import them.
Place all shared types in types/ and import rather than inline types.
Prefer server components for large subtrees; only add 'use client' at necessary boundaries.
Use clear folder namespacing for complex components and logical hook placement.

Example use cases

Refactor a large page component: extract subcomponents into separate .tsx files and move helpers to utils/.
Create a reusable hook: implement one hook per file under hooks/auth/useAuth.ts with no inline helpers or types.
Audit app router boundaries: convert non-interactive UI to server components and add 'use client' only where interactivity is needed.
Enforce code review checks: automatically flag files that export multiple components or contain inline types.
Organize a component library: use folder namespacing for complex components and keep stable hook APIs.

FAQ

Why one component per file?

One component per file improves clarity, makes imports predictable, simplifies testing, and reduces merge conflicts during team collaboration.

Where should small helper functions go?

Move helpers into utils/ grouped by area and import them. This keeps components and hooks focused and easier to test.

How do I decide client vs server components?

Prefer server components for non-interactive rendering and data fetching. Add 'use client' only at the smallest interactive boundary to avoid client-side cost.