Capítulo 47 de 116

Chapter 47: ESLint Plugin React Hooks — Rules Reference

Core Idea

Each rule in the plugin targets one specific way component/Hook code can violate the Rules of React — from the classic "don't call Hooks conditionally" to newer checks for purity, immutability, and correct effect timing that React Compiler also depends on.

Reference Tables

RuleWhat it flags
rules-of-hooksHooks called conditionally, in loops, or after an early return — violates the fixed-call-order requirement (Ch 116).
exhaustive-depsAn Effect/callback dependency array missing a reactive value the function body actually reads (Ch 38, Ch 40).
purityComponent or Hook bodies that perform side effects or non-deterministic reads during render, violating Ch 18's purity rule.
immutabilityCode that mutates props, state, or other values React expects to be treated as read-only (Ch 25/26).
set-state-in-renderCalling a state setter unconditionally during the render body itself, rather than in a handler/Effect.
set-state-in-effectAn Effect whose only job is setting state that could instead be computed directly during render — the Ch 37 anti-pattern, caught mechanically.
refsReading or writing ref.current during render instead of in an event handler/Effect (Ch 34).
static-componentsDefining a component function inside another component's body (Ch 11's "never nest component definitions" rule).
component-hook-factoriesFunctions that dynamically generate components or Hooks at runtime in ways that break the Rules of React's static-structure assumptions.
error-boundariesPatterns around error boundary components that don't follow the required class-component error-boundary contract.
incompatible-libraryUsage patterns from libraries known to conflict with the Rules of React or with compiler optimization assumptions.
preserve-manual-memoizationExisting manual useMemo/useCallback that the compiler can't safely preserve/subsume as-is.
unsupported-syntaxLanguage syntax the compiler's static analysis can't yet handle, flagged so the affected code is excluded from optimization rather than silently mishandled.
use-memoChecks specific to correct useMemo usage patterns (e.g. dependency correctness, no side effects inside the memoized calculation).

Key Takeaways

  1. Most of these rules exist to keep code compiler-optimizable, not just Hook-legal — a codebase clean under this full rule set is close to compiler-adoption-ready by construction.
  2. exhaustive-deps and rules-of-hooks are the two long-standing, must-never-disable rules; the rest are largely about the newer, broader Rules-of-React surface.
  3. When a rule fires on code that looks correct, treat it as a signal to re-examine the code's purity/immutability assumptions first — these rules are unusually good at catching subtle violations humans miss.

Connects To

  • Ch 46 (Setup & Configuration): how these rules get enabled in a project.
  • Ch 114-116 (Rules of React / Rules of Hooks): the underlying rules this plugin enforces mechanically.
  • Ch 45 (React Compiler — Debugging and Troubleshooting): where these same violation categories resurface as compiler-adoption bugs.