What is missing
Several components use the pattern of calling setState synchronously at the top of a `useEffect` body to reset/clear state when a dependency changes. This pattern is valid and works, but `eslint-plugin-react-hooks` v7 introduced a new rule `react-hooks/set-state-in-effect` that flags it as potentially causing cascading renders.
Affected files (rule currently disabled in `eslint.config.js`):
- `src/App.tsx` lines 35, 40, 48 — derived state resets on findingsError/activeRunId/events changes
- `src/components/PastRunsPane.tsx` line 41 — initial state reset before async fetch
- `src/components/SettingsPane.tsx` line 22 — initial state reset before async fetch
- `src/hooks/useFindings.ts` line 30 — reset findings before new async fetch
- `src/hooks/useTauriEvents.ts` line 56 — reset events when runId changes
Why it is deferred
Each fix requires a refactor: either computing derived state during render (replacing the state + effect pattern with a computed value), using `useRef` to track previous values, or restructuring the component to pass the initial state as a prop. These are non-trivial changes that could affect behaviour if done incorrectly, and they're outside the scope of the current lint setup PR.
Trigger
Pick this up when doing a performance audit or when the `react-hooks/set-state-in-effect` rule causes a real bug (cascading render in production). The rule is disabled with a comment in `eslint.config.js` explaining why.
What is missing
Several components use the pattern of calling setState synchronously at the top of a `useEffect` body to reset/clear state when a dependency changes. This pattern is valid and works, but `eslint-plugin-react-hooks` v7 introduced a new rule `react-hooks/set-state-in-effect` that flags it as potentially causing cascading renders.
Affected files (rule currently disabled in `eslint.config.js`):
Why it is deferred
Each fix requires a refactor: either computing derived state during render (replacing the state + effect pattern with a computed value), using `useRef` to track previous values, or restructuring the component to pass the initial state as a prop. These are non-trivial changes that could affect behaviour if done incorrectly, and they're outside the scope of the current lint setup PR.
Trigger
Pick this up when doing a performance audit or when the `react-hooks/set-state-in-effect` rule causes a real bug (cascading render in production). The rule is disabled with a comment in `eslint.config.js` explaining why.