);
}
// Restore-by-id: read ?id= from the URL with an SSR guard. Mirrors v1 (app/
// page.tsx) deliberately — next/navigation useSearchParams would force a
// Suspense boundary and break `next build`.
function readUrlId(): string | null {
if (typeof window === "undefined") return null;
return new URLSearchParams(window.location.search).get("id");
}
export default function TradeInV2Page() {
const router = useRouter();
const queryClient = useQueryClient();
const [nav, setNav] = useState(0);
const [drawerOpen, setDrawerOpen] = useState(false);
// #2264 C7: after a fresh estimate lands we move focus onto the result region
// (a labelled, tabIndex={-1} container in ResultPanel) so keyboard/SR users
// don't get dumped back on . `focusedEstimateRef` guards against
// re-focusing on unrelated re-renders / sub-hook updates.
const resultRegionRef = useRef(null);
const focusedEstimateRef = useRef(null);
// Locally-held just-computed estimate (so we render instantly after submit
// without a round-trip through the restore query).
const [freshResult, setFreshResult] = useState(
null,
);
// #2424 fix — router.replace(`?id=`) is an async client-navigation (RSC
// round-trip) that does NOT update window.location.search synchronously, but
// the onSelectEstimate handler below also calls setNav(0) in the same tick,
// which DOES force an immediate synchronous re-render. Without an override,
// that re-render's readUrlId() call reads the stale (pre-navigation) URL —
// and since this page has no other reactive subscription to the URL, the
// stale value is locked in forever (mirrors how `freshResult` already
// overrides the same race for the post-submit path below). Cleared once
// `restored.data` actually reflects this id (see effect below).
//
// Three states, not two: `undefined` means "no override, defer to
// readUrlId()"; `null` means "override to no-id" (handleNew's reset);
// a string means "override to this id" (a row was just clicked). Using
// plain `null` for both "no override" and "force no-id" was tried first and
// reintroduced this exact race for handleNew(): forcing pendingRestoreId
// from a bad id to `null` would, under `pendingRestoreId ?? readUrlId()`,
// fall through to readUrlId() on the very next render — which is still
// stale until router.replace("/v2") finishes — so the bad id came right
// back. The two intents need distinguishable values.
const [pendingRestoreId, setPendingRestoreId] = useState<
string | null | undefined
>(undefined);
const urlId = pendingRestoreId !== undefined ? pendingRestoreId : readUrlId();
// Post-mount flag: readUrlId() is null on SSR but a UUID on the client's first
// render, so any structure that depends on the id (e.g. the PDF vs disabled
//