perf(channels): stop rerendering message rows after each channel switch

[loganj]

🤖

Summary

• Switching back to a channel you already opened ("warm switching") got slower after the sidebar became persistent in Keep pages and channels in a persistent sidebar #234. The browser test that measures this fails when a switch takes more than 200 ms.
• Part of the extra time came from the message list. When you switch channels, the app hands the channel page its navigation state in two steps: first with no request, then with the new one. The channel page rebuilt its "open link" and "open media" functions each time that state changed, so right after the messages appeared, every message row rendered again to receive the new functions.
• Those two functions now look up the shown channel and navigation request when they are called. They stay the same across a switch, so message rows no longer render a second time.
• Nothing changes on screen. Links and media open exactly as before.

Details

• Change is in src/bundled/channels/ChannelsPage.tsx. It uses the same ref pattern the file already uses for link panel context (linkContext).
• Before Keep pages and channels in a persistent sidebar #234, the message rows were not yet mounted when the second step arrived, so this cost nothing. The persistent sidebar changed that timing.
• With the CPU slowed 4x to match CI speed, the median warm switch in tests/browser/channel-opening.spec.mjs fell from 193 ms to 165 ms when measured on top of perf(sidebar): stop rerendering every row's menu on channel switch #265 (24 samples each, same run). Component renders across the test's 4 switches fell from 8,522 to 5,380.
• Independent of perf(sidebar): stop rerendering every row's menu on channel switch #265 (which fixes sidebar row menus); either can land first. The 200 ms limit is unchanged.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Post-merge review: real, proportionate optimization; no introduced correctness blocker found. Reviewed 2e24935464c06376aa2706deba01c200ba7d4aa5 against 80511fa86c2543e10447779c451ecfaf4652bff6. Already merged as fff36cc7.

• Causality: navigation presentation is installed in a layout effect after an owner change (src/app/navigation.ts:120–166). Previously that handoff changed both callback props through the memoized timeline. In an isolated build-time probe of the existing warm-switch journey, substituting the exact base version of the sole changed file produced 83 MessageRow calls across four switches versus 48 with this patch. Callback identities changed in the base variant and stayed stable in the patched variant. This reproduction did not include #265.
• Safety: the ref records the committed visible destination, rather than an unfinished render. Existing consumers invoke it synchronously; workspace/channel remounts and existing navigation/session authority checks preserve ownership. An isolated production-broker journey passed Chromium and WebKit: repeated channel visits, correct image/thread targets, keyboard activation and focus restoration, channel links/back, and viewer invalidation on back/forward. Three independent source-review lanes were reconciled with this runtime evidence.
• Limits/follow-up: this proves reduced render work, not the reported 193→165 ms latency magnitude. My one-run-per-variant timings overlap; hosted before/after runners also differ. No committed regression test guards this mechanism, so add a deterministic row-render/callback regression test rather than relying only on the 200 ms ceiling. PR CI passed on rerun; Windows was skipped. Merged-main CI 36165809509 was pending at the checked snapshot. No full-suite rerun or native/live-service validation performed.

The new interaction probe initially expected root text that this viewer intentionally omits; corrected to verify a signed reply and image URL. A WebKit pointer-focus assertion also failed with the base implementation; explicit keyboard activation passes both engines. Neither was an introduced regression. No approval submitted.