Skip to content

Commit f6ac075

Browse files
cliffhallclaude
andauthored
fix(servers): make settings form re-render on every keystroke (#1361) (#1362)
* 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>
1 parent 037225a commit f6ac075

3 files changed

Lines changed: 588 additions & 76 deletions

File tree

clients/web/src/App.tsx

Lines changed: 52 additions & 76 deletions
Original file line numberDiff line numberDiff line change
@@ -30,6 +30,7 @@ import { StderrLogState } from "@inspector/core/mcp/state/stderrLogState.js";
3030
import type { RedirectUrlProvider } from "@inspector/core/auth/index.js";
3131
import { useInspectorClient } from "@inspector/core/react/useInspectorClient.js";
3232
import { useServers } from "@inspector/core/react/useServers.js";
33+
import { useSettingsDraft } from "@inspector/core/react/useSettingsDraft.js";
3334
import { useManagedTools } from "@inspector/core/react/useManagedTools.js";
3435
import { useManagedPrompts } from "@inspector/core/react/useManagedPrompts.js";
3536
import { useManagedResources } from "@inspector/core/react/useManagedResources.js";
@@ -126,6 +127,19 @@ function messagesToLogEntries(messages: MessageEntry[]): LogEntryData[] {
126127
return out;
127128
}
128129

130+
// Stable empty-shell for `InspectorServerSettings`. Used both as the
131+
// initial draft for a server entry that hasn't been touched yet, and as
132+
// the fallback the settings modal renders against when it's closed
133+
// (Mantine renders the dialog shell regardless of `opened`). Hoisted to
134+
// module scope so both call sites share the same object identity and so
135+
// React doesn't re-allocate on every render.
136+
const EMPTY_SETTINGS: InspectorServerSettings = {
137+
headers: [],
138+
metadata: [],
139+
connectionTimeout: 0,
140+
requestTimeout: 0,
141+
};
142+
129143
function App() {
130144
// Theme toggle plumbing (preserved from the pre-wire placeholder).
131145
const { setColorScheme } = useMantineColorScheme();
@@ -763,90 +777,52 @@ function App() {
763777
return servers.find((s) => s.id === configModal.targetId);
764778
}, [configModal, servers]);
765779

766-
const settingsModalTarget = useMemo(() => {
767-
if (!settingsModalTargetId) return undefined;
768-
return servers.find((s) => s.id === settingsModalTargetId);
769-
}, [settingsModalTargetId, servers]);
770-
771-
// Stable starting shape for entries that have no `settings` node yet — the
772-
// form needs concrete arrays / numbers to render.
773-
const settingsModalValue = useMemo<InspectorServerSettings>(() => {
774-
return (
775-
settingsModalTarget?.settings ?? {
776-
headers: [],
777-
metadata: [],
778-
connectionTimeout: 0,
779-
requestTimeout: 0,
780-
}
781-
);
782-
}, [settingsModalTarget]);
783-
784-
// The settings modal fires onSettingsChange on every keystroke. Persisting
785-
// each character would run a tight PUT-then-full-refresh loop against the
786-
// backend (and the in-memory `servers` state could flicker mid-typing as
787-
// each refresh resets the modal's prop). Debounce so a burst of edits
788-
// coalesces into a single PUT, and flush on modal close so nothing is lost.
789-
const pendingSettingsRef = useRef<{
790-
id: string;
791-
settings: InspectorServerSettings;
792-
} | null>(null);
793-
const pendingSettingsTimerRef = useRef<
794-
ReturnType<typeof setTimeout> | undefined
795-
>(undefined);
796-
797-
const flushPendingSettings = useCallback(() => {
798-
if (pendingSettingsTimerRef.current) {
799-
clearTimeout(pendingSettingsTimerRef.current);
800-
pendingSettingsTimerRef.current = undefined;
801-
}
802-
const pending = pendingSettingsRef.current;
803-
if (!pending) return;
804-
pendingSettingsRef.current = null;
805-
// Fire-and-forget — but surface failures via toast. The modal closes
806-
// immediately on user dismiss, so a silent fail-on-flush would leave
807-
// the user thinking their last edits saved when they didn't (especially
808-
// painful for the OAuth client secret).
809-
updateServerSettings(pending.id, pending.settings).catch((err) => {
780+
// The settings modal is fully controlled — every input change fires
781+
// `onSettingsChange` back up here, and the input's `value` prop only
782+
// updates when this component re-renders with a new `settings` prop.
783+
// We hold the in-progress draft in `useSettingsDraft` so every change
784+
// re-renders synchronously; the hook also debounces the PUT and
785+
// exposes `flush` for the close handler to call. The draft is
786+
// (re)initialized only when the modal opens to a *different* server,
787+
// which is why a background refresh of `servers` can run without
788+
// clobbering in-progress edits.
789+
//
790+
// `resolveInitial` reads `servers` from this render's closure — that
791+
// works because the settings entry point is the "Settings" button on
792+
// a rendered server card, so `servers` is always non-empty by the
793+
// time this hook is called. A future caller that opens the modal
794+
// from elsewhere (e.g. a keyboard shortcut on initial load) would
795+
// need a different initialization path; the empty-shell fallback at
796+
// least keeps the form renderable while `servers` hydrates.
797+
const {
798+
draft: settingsDraft,
799+
onChange: onSettingsChange,
800+
flush: flushSettingsDraft,
801+
} = useSettingsDraft<InspectorServerSettings>({
802+
targetId: settingsModalTargetId,
803+
resolveInitial: (id) =>
804+
servers.find((s) => s.id === id)?.settings ?? EMPTY_SETTINGS,
805+
onPersist: updateServerSettings,
806+
// Surface failures via toast — the modal usually closes
807+
// immediately on user dismiss, so a silent fail-on-flush would
808+
// leave the user thinking their last edits saved when they
809+
// didn't (especially painful for the OAuth client secret).
810+
onError: (id, err) => {
810811
notifications.show({
811-
title: `Failed to save settings for "${pending.id}"`,
812+
title: `Failed to save settings for "${id}"`,
812813
message: err instanceof Error ? err.message : String(err),
813814
color: "red",
814815
});
815-
});
816-
}, [updateServerSettings]);
817-
818-
const onSettingsChange = useCallback(
819-
(next: InspectorServerSettings) => {
820-
if (!settingsModalTargetId) return;
821-
pendingSettingsRef.current = {
822-
id: settingsModalTargetId,
823-
settings: next,
824-
};
825-
if (pendingSettingsTimerRef.current) {
826-
clearTimeout(pendingSettingsTimerRef.current);
827-
}
828-
pendingSettingsTimerRef.current = setTimeout(flushPendingSettings, 300);
829816
},
830-
[settingsModalTargetId, flushPendingSettings],
831-
);
817+
});
818+
819+
const settingsModalValue: InspectorServerSettings =
820+
settingsDraft ?? EMPTY_SETTINGS;
832821

833822
const onSettingsModalClose = useCallback(() => {
834-
flushPendingSettings();
823+
flushSettingsDraft();
835824
setSettingsModalTargetId(undefined);
836-
}, [flushPendingSettings]);
837-
838-
// Cancel any pending debounce on unmount (route change / HMR). Without
839-
// this a stale setTimeout could still fire one final `updateServerSettings`
840-
// against an unmounted component — harmless today (just an extra PUT of
841-
// the final payload) but the cleanest pattern is to clear the timer.
842-
useEffect(() => {
843-
return () => {
844-
if (pendingSettingsTimerRef.current) {
845-
clearTimeout(pendingSettingsTimerRef.current);
846-
pendingSettingsTimerRef.current = undefined;
847-
}
848-
};
849-
}, []);
825+
}, [flushSettingsDraft]);
850826

851827
// The Resources screen needs `isSubscribed` to flip the Subscribe button
852828
// label to "Unsubscribe". Derive it from the live subscriptions list rather

0 commit comments

Comments
 (0)