ref(seer): Persist Seer Explorer input draft per run

[aliu39]

Summary

• Add useDeferredSessionStorage<T>(key, initialValue) in static/app/utils/, a generic sessionStorage hook with deferred writes — storage is only touched on key change, unmount, or explicit reset(). No per-keystroke main-thread writes.
• Extract readStorageValue / writeStorageValue / removeStorageValue helpers in useSessionStorage.tsx and share them with the new hook. useSessionStorage itself now accepts key: string | null, with null disabling persistence (matches the new hook's behavior).
• Wire useDeferredSessionStorage into the Seer Explorer drawer keyed by runId, so the textarea draft survives drawer close/reopen and run switches.

Behavior notes

• handleSend calls reset(), which wipes both state and storage for the current runId.
• Closing the drawer (component unmount) flushes the current draft to its runId's key.
• Switching runs auto-saves the current run's draft to its key and loads the new run's draft.
• When runId is null (no session yet), the draft lives in React state only — nothing is read from or written to sessionStorage. Drafts only start persisting once a run exists.
• The hook's auto-flush on key change replaces the previous onSuccess: clearInput plumbing in startNewSession / switchToRun.

Tests

Added an Input Persistence block to explorerDrawerContent.spec.tsx:

• Restores the persisted draft when the drawer remounts.
• Persists the draft per runId across run switches.
• Never writes to sessionStorage when runId is null.
• Clears the persisted draft when a message is sent.

Test plan

• Type a partial message in the drawer with an active session, close it, reopen — draft is restored.
• Type in run A, switch to run B, switch back — each run shows its own draft.
• Open the drawer with no active session, type, close — nothing in sessionStorage.
• Send a message — input clears and sessionStorage for that runId is removed.
• Refresh the page (same tab) — drafts persist; open a new tab — drafts not shared (sessionStorage scope).

[github-actions]

📊 Type Coverage Diff

✅ No new type safety issues introduced. Coverage: 93.59%

[ryan953]

this looks similar to useLocalStorageState. you could use that and pass in the same kind of key

[natemoo-re]

None of our existing use*Storage hooks support deferred writes like this hook, which avoids hammering storage on every keystroke in a textarea.

There's certainly an argument to be made that we should add an option for one of those hooks to support it, though.

[ryan953]

i'd aim to layer a throttle or something, instead of baking things in

[aliu39]

@ryan953 do you mean to throttle the number of updates to local/session storage?

[ryan953]

I don't have strong enough opinions to block this PR. But I'll think it all through (rant) since we're here...

I was sorta alerted because i know the llms love to make new files instead of finding existing ones, and i think that kind of duplication was already a problem and it'll get much worse over time.

So we've got the base useLocalStorageState, which is the place that does serialization as well as the setState call (2 jobs). I'd argue that those two jobs could be split up a little better; the benefit could be that we don't need to have readValue() and writeValue() re-implemented.
I also found NoteInputWithStorage which is another implementation of the persist-unsaved-content pattern. It's got debounce() to wrap the save call, evidence that its a great call to have here too 👍 . It would be ideal if that component were composable, so we could just use it directly. Instead its coupled to NoteInput.

This kind of circles back to the idea that there are multiple similar implementations all over and they're hard to find. So if we keep this file i'd move it into something like static/app/utils/storage. The NoteInput isn't obvious to find, and who wants to share by importing from components/activity/note/

So yeah, not trying to block this. brain dump for y'all.

[aliu39]

Makes sense, thanks for the thoughts! I can move to app/utils so its easier to find, and see if we can reuse read/write

[natemoo-re]

Nice!

Waiting until we resolve hook duplication discussion

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 158e036. Configure here.}

[cursor]

Unmount cleanup re-writes value after explicit reset

Low Severity

The unmount cleanup effect unconditionally writes valueRef.current to storage, which re-creates a storage entry that reset() explicitly removed via sessionStorageWrapper.removeItem. After handleSend calls clearInput() (i.e., reset()), closing the drawer triggers the unmount cleanup and writes the initialValue back under the same key, creating a zombie entry in sessionStorage. The test for "clears the persisted draft when a message is sent" only passes because it asserts before unmount occurs.

Additional Locations (1)

• static/app/utils/useDeferredSessionStorage.tsx#L51-L57

 

^{Reviewed by Cursor Bugbot for commit 158e036. Configure here.}

[aliu39]

wont affect functionality, just an extra storage write on this edge case