`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>
* fix(servers): make settings form re-render on every keystroke (#1361)
The settings modal is fully controlled by App.tsx, but pending edits were
stashed in a useRef — refs don't trigger re-renders, so the input's `value`
prop stayed stale until the 300ms debounce + PUT + refetch round-tripped.
Clicking "Add Header" / "Add Metadata" showed no row, and typing in OAuth
fields had no character echo, until that round-trip completed (~500ms).
The bug landed in #1353 with the debounced-flush pattern. It surfaced after
#1356 because per-keystroke PUTs now also write the keychain, making the
round-trip latency more noticeable.
Lift the draft into `useState`. Every change re-renders the modal
immediately. Keep the 300ms debounce on the PUT side. Initialize the draft
from the server-list entry only when the modal opens to a new target (not
on every `servers` change) so background refreshes don't clobber the user's
in-progress edits. Flush on close to preserve final keystrokes.
Verified live against the dev server: header/metadata rows appear on click,
OAuth Client ID / Client Secret typing echoes without lag, and the values
persist correctly (clientId in mcp.json, clientSecret in the macOS
Keychain).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* chore(servers): extract useSettingsDraft hook + tests; review polish (#1361)
Picks up the three review observations on #1362:
1. Extract the draft state + debounce + flush logic from App.tsx into
`core/react/useSettingsDraft`. Same behavior; thinner App.tsx;
testable in isolation with `renderHook`. Tests pin the regression
#1361 was about (synchronous onChange → draft update) plus the
debounce window, burst-collapse, flush-on-close, error propagation,
and the "background refresh must not clobber in-progress edits"
contract via a `resolveInitial` closure swap.
2. Hoist the empty `InspectorServerSettings` fallback to a module-scope
`EMPTY_SETTINGS` const. Both the hook's init path and the modal's
closed-state fallback share the same object identity; the inline
`useMemo` that previously re-derived it is gone.
3. Add a comment on the `resolveInitial` callback noting that we read
`servers` from this render's closure under the assumption that the
entry point is the "Settings" button on a rendered server card.
Documents the contract for future callers (e.g. a keyboard shortcut
that opens the modal pre-hydration).
Validate clean: 1756 tests pass. New useSettingsDraft.test.tsx adds 13
test cases.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* chore(servers): stabilize flush identity + add unmount-cleanup test (#1361)
Two non-blocking observations from the third review on #1362:
1. `flush` identity churned on every keystroke because the useCallback
closed over `draft` + `targetId`. Read both through refs instead so
the returned callback identity is stable. The behavior is unchanged
— but the consumer's `onSettingsModalClose` (which wraps `flush`)
no longer re-allocates per keystroke, which means the modal's
`onClose` prop identity also stays stable. A new test pins this.
2. Added a comment in `onChange` calling out that callers switching
`targetId` mid-debounce must `flush()` first to preserve the
pending PUT. The only switch path today (`onSettingsModalClose` in
App.tsx) does that already — the comment is for future refactors.
3. New unmount-cleanup test pins the intentional "drop final
<debounceMs window on unmount" trade-off — flushing on unmount
could fire a PUT against an unmounting component, which is a
worse footgun than losing a few hundred ms of typing on route
change / HMR.
Validate clean: 144 files, 1758 tests pass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
cliffhall