chore: lint core/react with eslint-plugin-react-hooks (#2192)

`eslint-plugin-react-hooks` was a `clients/web` devDependency only, and each
client's `eslint .` is scoped to its own directory — so the whole hook rule
set had never looked at `core/react/`, a directory of nothing but React
hooks. "Neither surface has JSX" was the stated reason and was never a good
one: the rules judge hooks, not JSX.

Add the plugin at the root and apply it in a `core/react/**` block (scoped
there rather than to all of `core/**`, since the rules key off the `use`
prefix), with `exhaustive-deps` promoted to `error` as `clients/web` does.

Resolve the 15 findings it then reports:

- `useSettingsDraft` / `useClientSettingsDraft` seed their draft during
  render instead of in a `targetId`/`opened`-keyed effect, so the previous
  target's values never reach the DOM — the same rule `clients/web` spells
  `useValueChange`. Their "latest value" refs move from render-time writes
  into an effect; every reader (the debounce timer, `flush`, `onChange`)
  runs after a commit, so a post-commit write is what they need.
- The three async loaders keep their effects behind justified inline
  disables: `set-state-in-effect` follows a call into an async function
  without modelling the `await`, verified against a minimal hook whose only
  setState is in a continuation.
- `useInitialConfig`'s cleanup bump keeps reading `generation.current` at
  teardown — the rule's "copy it into a variable" advice would restore a
  stale request token and let a superseded response commit.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013hzwzS8UvBsr4yZm7o7sev
Signed-off-by: cliffhall <cliff@futurescale.com>
This commit is contained in:
cliffhall 2026-08-29 23:17:45 -04:00
commit 9ced0fd150
5 changed files with 680 additions and 57 deletions

View file

@ -33,25 +33,33 @@ export function useClientSettingsDraft<T>({
const timerRef = useRef<ReturnType<typeof setTimeout> | undefined>(undefined);
const latestValuesRef = useRef<T | null>(null);
const resolveInitialRef = useRef(resolveInitial);
// Seeded during render rather than in an effect, for the reason spelled
// out on {@link useSettingsDraft}: an effect would paint the previous
// session's draft for one frame before correcting itself. `seeded` is
// tracked separately from `draft` so a `resolveInitial` that legitimately
// returns `null` is not re-seeded on every render.
const [seeded, setSeeded] = useState(false);
if (seeded !== opened) {
setSeeded(opened);
setDraft(opened ? resolveInitial() : null);
}
const onPersistRef = useRef(onPersist);
const onErrorRef = useRef(onError);
const openedRef = useRef(opened);
resolveInitialRef.current = resolveInitial;
onPersistRef.current = onPersist;
onErrorRef.current = onError;
openedRef.current = opened;
// Written in an effect rather than during render (`react-hooks/refs`).
// Every reader — the debounce timer, `flush`, and `onChange` — runs after
// a commit, so a post-commit write is what they need. `latestValuesRef`
// mirrors `draft` here so it is re-seeded (and cleared on close) without a
// second copy of the seeding rule; `onChange` still writes it
// synchronously, because a functional update in the same tick has to see
// the value the previous call produced.
useEffect(() => {
if (!opened) {
setDraft(null);
latestValuesRef.current = null;
return;
}
const initial = resolveInitialRef.current();
setDraft(initial);
latestValuesRef.current = initial;
}, [opened]);
onPersistRef.current = onPersist;
onErrorRef.current = onError;
openedRef.current = opened;
latestValuesRef.current = draft;
});
useEffect(() => {
return () => {

View file

@ -35,6 +35,16 @@ export function useEmaIdpLoginState(
useEffect(() => {
if (!active) return;
// Reading the persisted IdP session *is* the external system this effect
// exists to synchronize with, and the read is asynchronous: the
// `loginState` commit happens in a continuation after
// `getEmaIdpLoginState` resolves. `set-state-in-effect` follows the call
// into `refresh` without modelling the `await`, so it reports every
// "fetch on open" effect alike — verified against a minimal hook whose
// only setState is after an `await`. The one commit here that *is*
// synchronous is the no-issuer reset to "none", which settles in a single
// extra render rather than cascading.
// eslint-disable-next-line react-hooks/set-state-in-effect -- async read of an external store
void refresh();
}, [active, refresh]);

View file

@ -245,11 +245,25 @@ export function useInitialConfig(
}, [base, authToken, doFetch]);
useEffect(() => {
// `load` commits nothing before its first `await`: it claims a generation
// token, builds headers, and only then fetches, so every setState it makes
// runs in a continuation. `set-state-in-effect` follows the call into an
// async function without modelling the `await` boundary, so it reports
// this even though there is no synchronous commit to cascade from.
// eslint-disable-next-line react-hooks/set-state-in-effect -- no commit before the first await
void load();
return () => {
// Invalidate whatever is in flight: this fires on unmount and on a
// `baseUrl`/`authToken` change, and in both cases a response for the
// old inputs must not commit.
//
// `generation` is a monotonic request token, not a ref to a rendered
// node. `exhaustive-deps`' advice — copy `generation.current` into a
// variable inside the effect and use the copy here — is exactly wrong:
// the cleanup must bump whatever the counter holds *at teardown*, since
// that is what invalidates the load currently in flight. A value
// captured at effect setup would let a superseded response commit.
// eslint-disable-next-line react-hooks/exhaustive-deps -- must read the token at teardown
generation.current++;
};
}, [load]);

View file

@ -231,6 +231,14 @@ export function useServers(opts: UseServersOptions): UseServersResult {
);
useEffect(() => {
// Loading the server list from the backend is the external-system
// synchronization this effect is for, and every list/error commit happens
// after `loadServers()` resolves. `set-state-in-effect` follows the call
// without modelling the `await`, so it reports the whole shape. The
// synchronous part is the pair that *opens* a load — `setLoading(true)`
// and clearing a stale error — which settles in one extra render, and is
// the point of having a loading flag at all.
// eslint-disable-next-line react-hooks/set-state-in-effect -- async load of an external list
void refresh();
}, [refresh]);

View file

@ -28,11 +28,12 @@ export interface UseSettingsDraftOptions<T> {
targetId: string | undefined;
/**
* Resolves the initial draft for a given server id at the moment the
* modal opens. Called once per target — must be stable enough that
* the caller doesn't accidentally provoke re-initialization while
* the user is editing. (We do not include this function in the
* effect deps; it's read through a ref so callers don't have to
* `useCallback` it.)
* modal opens. Called once per target, **during render** — so it must
* be pure: a render can be replayed under StrictMode or abandoned by
* concurrent React, which would run any side effect an unpredictable
* number of times. Its identity is never a dependency of anything, so
* callers do not have to `useCallback` it, and re-creating it on every
* render cannot re-seed an in-progress edit.
*/
resolveInitial: (id: string) => T;
/** Persist the draft. Called from the debounced flush and from `flush`. */
@ -73,31 +74,41 @@ export function useSettingsDraft<T>({
const [draft, setDraft] = useState<T | null>(null);
const timerRef = useRef<ReturnType<typeof setTimeout> | undefined>(undefined);
// Seeding happens during render, not in an effect. An effect keyed on
// `targetId` renders once with the *previous* target's draft, paints
// it, and only then corrects itself — so opening the modal on a second
// server briefly shows the first one's values. React's documented
// "adjusting state when a prop changes" pattern discards the
// in-progress render instead, so nothing stale reaches the DOM.
// (`clients/web` spells the same thing `useValueChange`; `core/` cannot
// import from a client.)
//
// `seededFor` is compared rather than `draft`, because "already seeded
// for this target" and "the draft happens to be null" are different
// states: a caller whose `resolveInitial` legitimately yields `null`
// would otherwise be re-seeded on every render.
const [seededFor, setSeededFor] = useState<string | undefined>(undefined);
if (seededFor !== targetId) {
setSeededFor(targetId);
setDraft(targetId ? resolveInitial(targetId) : null);
}
// Read callbacks (and the current draft) through refs so the consumer
// doesn't have to `useCallback` them, and so the returned `flush`
// identity is stable across keystrokes. The effect that
// re-initializes the draft must depend on `targetId` only — anything
// else in its deps risks resetting an in-progress edit when the
// parent re-renders for unrelated reasons (e.g. a background
// server-list refresh).
const resolveInitialRef = useRef(resolveInitial);
// identity is stable across keystrokes. Written in an effect rather
// than during render (`react-hooks/refs`): a render can be replayed or
// abandoned, and every reader here — the debounce timer and `flush` —
// runs after a commit, so a post-commit write is what they need.
const onPersistRef = useRef(onPersist);
const onErrorRef = useRef(onError);
const draftRef = useRef<T | null>(null);
const targetIdRef = useRef(targetId);
resolveInitialRef.current = resolveInitial;
onPersistRef.current = onPersist;
onErrorRef.current = onError;
draftRef.current = draft;
targetIdRef.current = targetId;
useEffect(() => {
if (!targetId) {
setDraft(null);
return;
}
setDraft(resolveInitialRef.current(targetId));
}, [targetId]);
onPersistRef.current = onPersist;
onErrorRef.current = onError;
draftRef.current = draft;
targetIdRef.current = targetId;
});
// Unmount cleanup — a stale timer firing after unmount is harmless
// today (the persist call still goes through to the backend) but