Problem
After compacting the server-function solve envelope, rendering is the next scaling limit for large production blocks.
On the current Primary Mall block:
- 57 recipe rows
- about 7,260 DOM nodes after render
- about 340 ms from client-side navigation to all recipe rows being present in a local dev browser
- solve transport is now about 137 KB on the wire, down from about 688 KB, so further transport trimming is no longer the dominant lever
The grid currently mounts every row and all item chips, hover triggers, tooltips, logistics tags, and drag/drop wrappers at once. This will continue to grow with mall and late-game blocks.
Scope
- Profile render/commit cost for large blocks independently from solve/server time.
- Virtualize or progressively mount recipe rows while preserving:
- drag-and-drop ordering
- row highlighting and scroll-to-row
- editable counts and focus during live saves
- group headers and composed sub-blocks
- hover cards, context menus, and dialogs
- responsive no-horizontal-overflow behavior
- Add a stable large-block performance regression fixture or threshold that does not depend on a user's project DB.
Keep solver inputs/results and persistence behavior unchanged.
Problem
After compacting the server-function solve envelope, rendering is the next scaling limit for large production blocks.
On the current Primary Mall block:
The grid currently mounts every row and all item chips, hover triggers, tooltips, logistics tags, and drag/drop wrappers at once. This will continue to grow with mall and late-game blocks.
Scope
Keep solver inputs/results and persistence behavior unchanged.