Project: React permit review queue state

Last updated: 5 Oct 20269 min read

project

Build a React permit queue for cases 29, 47, 62, and 81. A reviewer can search 47,000 summaries, open a case, write a private note, and approve it. The first page view comes from server-rendered markup. The queue must keep a note attached to its case when new records are inserted or sorting changes. Switching cases must not copy the previous note into a new case; if drafts should survive, persist them by case ID before the editor resets. The search box should follow typing promptly while its result list catches up. A saved browser filter can apply after hydration, but the first client render must agree with the server snapshot. Approval is a user command and must never fire merely because restored state says approved.

Build contract

Key queue rows by immutable case ID and key only the editor subtree whose case ownership changes.
Derive visible cases and count from source cases plus the search phrase; send approval only from an explicit command path.
Keep input text urgent, allow result rendering to lag, and reject responses from an older search generation.
Pass a versioned server snapshot into the first client render; apply browser-only preferences after hydration.

Implementation checkpoint

function selectCurrentSearch(responseGeneration, activeGeneration, responseCases) {
  return responseGeneration === activeGeneration ? responseCases : null;
}
console.log(selectCurrentSearch(62, 81, [{ id: 47 }]));
// Output: null

Cost and boundaries

Keying the editor by case ID can remount an expensive subtree and remove focus; it should be the smallest boundary that matches draft ownership. A draft store consumes memory and must clear records after submission, logout, or expiry. Calculating a filtered list during render is simpler than synchronizing another copy through an effect, but 47,000 records may justify a measured memo, index, worker, or windowed view. A transition can prioritize keystrokes over result rendering; it cannot interrupt one long synchronous calculation or fix a stale network response. A server snapshot adds response bytes and requires safe serialization. Applying browser preferences after hydration may add a second visible render, so design that change plainly.

Failure drill

Type a note for case 47, insert case 29 ahead of it, reverse the sort, and confirm the note's owner remains 47. Switch to case 81 and back; verify the declared discard or preservation rule. Change only a toolbar label and check that note focus remains. Restore an approved record from a saved snapshot without sending an approval request. Type search phrases that issue generations 62 and 81, return generation 81 first, then return 62; the older list must be ignored. Delay the bundle, hydrate under a different time zone and saved filter, and compare server HTML with the first client render. Finally, reject an approval and check that the visible state becomes truthful again.

Acceptance checks

A reorder never moves a draft or pending result to a different case ID.
Visible count and rows agree during typing, refresh, and server rejection.
Input response and settled-result time are measured separately on a modest device.
The first client render matches server markup before local preferences apply.

Common Mistakes

Using row index keys in a sortable queue.
Posting mutations from an effect that watches a restored flag.
Assuming a transition orders network replies or repairs hydration mismatch.

web-tech

web-development