react-single-responsibility

Apply these strategies to keep components, hooks, and methods focused, testable, and readable. Rules are split by file type into dedicated reference files — load only the one matching the code being simplified.

---

Principles

| Principle | Rule | | ------------------------- | --------------------------------------------------------------------------------------------- | | KISS | Simplest solution that works. Avoid over-engineering. | | Single responsibility | One clear responsibility per component or function; extract utilities, hooks, sub-components. | | DRY | Extract common logic; create reusable functions or components. | | Composition | Prefer composing small components and utilities over large, multi-purpose blocks. |

---

Which rules apply

Use the file where the function lives to pick the reference file:

• *.tsx → components → references/component-simplification.md
• use*.ts → hooks → references/hook-simplification.md
• *.ts (plain functions) → methods → references/method-simplification.md

Plain TypeScript functions are always in *.ts, never in *.tsx. Load the matching reference file first, then apply the Shared rules below regardless of file type.

---

Shared (components, hooks, and methods)

Object destructuring

• Use object destructuring when reading or passing object attributes so that attribute names are explicit and the code stays readable. Applies to: component props (e.g. const { isLoading, error, data } = props or in the signature), function parameters (e.g. const fn = ({ a, b }: FnArgs) => ...), and local objects when you use several properties (e.g. const { name, status } = item). Prefer destructuring when it clarifies usage and improves readability; avoid when a single property is used once.
• Parameter object (2+ args) — As soon as a function has more than one parameter, use a single options object with destructuring and extract the parameter interface immediately above the signature. Applies to every function: component, hook, or method.
• Default at destructure time — When a value can be undefined, apply its fallback once at destructuring (const { x = fallback } = source) instead of repeating x ?? fallback at every call site that reads it.
• Destructure repeated access once — When the same nested property (e.g. i18n.language) is read several times in one scope, destructure it once near the top (const { language } = i18n, or const { i18n: { language } } = useTranslation()) and reuse the local binding.

Coupling (shotgun surgery)

• Signal: One feature change requires edits in many files.
• Fix: Co-locate related logic (e.g. feature folder with its own components, hooks, utils, types); reduce coupling and centralize domain logic where it belongs.

File and size guidelines

• *.tsx (components) — Must not exceed 150 lines. Plain functions live in *.ts, not in *.tsx.
• *.ts (pure TypeScript) — 200–400 lines typical per file; 2000 lines absolute maximum. Plain functions (methods) use the per-function threshold defined in references/method-simplification.md.
• File names: kebab-case. Examples: market-list-item.tsx, use-market-filters.ts, <name>.utils.ts, (e.g. market-list.utils.ts).

Quick checklist

• [ ] Does it do more than one thing? → if yes: extract pure utilities, hooks, or sub-components (component) or smaller named functions (method).
• [ ] More than 1 parameter? → see Parameter object rule above.
• [ ] Copy-pasted code? → extract and parameterize.
• [ ] Control flow deeply nested? → use early returns and intermediate variables.
• [ ] Comments explaining what? → rename for self-documenting code; keep comments for why only.
• [ ] Inside a class and re-computing derived state? → extract a getter (get xyz() { return ... }) to promote DRY and simplify method bodies.