# Skill: Generate clean React/Next.js code with proper components, props, state, and server/client split

> Apply this skill when building any React or Next.js interface -- it prevents the common failure modes of giant monolithic files, duplicated blocks, misconfigured state, and mixed server/client code.

Source: sodigi·learn -- vibecoding/react-po-chelovecheski · https://sodigi.io/learn/vibecoding/react-po-chelovecheski

## When to use
- Generating a new React page, feature, or component set.
- Diagnosing a flickering, lagging, or mysteriously breaking React UI.
- Reviewing agent-produced React code before accepting it -- check for the one-slab antipattern.
- Building a Next.js page that needs both database access and interactive UI elements.

## Core rules
- Every chunk of UI is a component. A component does one thing. If its name requires "and," split it.
- Data that comes from outside the component belongs in props. Internal changeable state belongs in useState/useReducer. Never duplicate the same data in both.
- Derive computed values on the fly -- never store in state something you can calculate from other state. Storing "total" separately from "items" will drift.
- In Next.js: server components load data and hold secrets; client components handle clicks, input, and animation. Mark client components with "use client". Never let secrets travel to the browser.
- Reuse components with different props instead of copy-pasting the same block with minor tweaks.
- Give every item in a list a stable key based on a unique ID, not the array index.
- Search/filter inputs must debounce -- do not fire a query on every keystroke.

## Procedure
1. Before writing code, output the component tree as a named list: which components exist, what each one does, what props it receives.
2. Wait for approval of the structure, then write the code.
3. Identify which data is server-side (DB queries, secrets) and which is client-side (interactive state). Mark client components explicitly.
4. Pull any repeated block into a single shared component with props for the varying parts.
5. Audit state: for each useState, confirm it stores something that changes at runtime and cannot be derived from other state.
6. Add a debounce delay (~500ms) to any input that triggers data loading.
7. Assign stable id-based keys to all list items.

## Ready-to-use prompt
```
Build [describe the feature] in React and Next.js. Requirements:

1. Split it into small components: each component does exactly one thing.
   Name each component clearly.
2. Pass all external data through props. Never fetch from the database inside
   a presentational component.
3. Keep in state only what actually changes at runtime. Compute filtered
   lists, totals, and other derived values on the spot -- do not store them
   separately.
4. Add a ~500ms delay to any search or filter input so it does not fire
   on every keystroke.
5. Give every item in a list a stable key based on its id, not its position.
6. Mark any component that uses clicks, forms, or animation with "use client".
   Components that only load data or use secrets must be server components.

First show me the component structure as a list and wait for my OK, then
write the code.
```

## Pitfalls
- Generating one 900-line file with everything in it -- fixing one thing breaks everything else because it is all tangled together.
- Copy-pasting the same block five times with tiny differences instead of making one component with props -- five copies mean five places to fix every future bug.
- Duplicating derived data in state (storing both "items" and "total" separately) -- they drift out of sync and produce impossible-to-debug inconsistencies.
- Mixing server and client code in Next.js -- database calls in a "use client" component, or useState in a server component, both fail at runtime.
- Firing a search query on every keystroke -- causes visible twitching and hammers the database needlessly.
- Using array index as list key -- causes React to reorder or re-render the wrong items when the list changes.