Chapter 14, Lists with 10,000 items, page 83
Lists with 10,000 items
Failure signal
Ledger’s feed had 10,000 rows and used a LazyVStack, so the team believed the list was handled. Typing into search still froze the screen for hundreds of milliseconds per keystroke. The container was lazy, which meant rows were constructed on demand, but every keystroke normalized, filtered, grouped, and sorted the entire dataset on the main actor before any lazy construction happened, and unstable ids then caused broad row replacement on top of that. The lazy container had solved the one problem it solves and left every other problem in the pipeline untouched. “It is lazy” is not “it is fast.”
The decision
Design the complete data-to-row pipeline, not just the container: stable identity, bounded snapshots, filtering done off the main actor and cached, pagination with a gate, a prefetch policy, cheap row bodies, and measured image work. A large list is a pipeline, and its performance is the performance of its slowest stage, which is almost never the container.
