Skip to content

Prefetch thread bootstrap when a sidebar row receives keyboard focus - #14

Merged
Guitaraholic merged 1 commit into
mainfrom
fix/thread-row-focus-prefetch
Sep 2, 2026
Merged

Prefetch thread bootstrap when a sidebar row receives keyboard focus#14
Guitaraholic merged 1 commit into
mainfrom
fix/thread-row-focus-prefetch

Conversation

@Guitaraholic

Copy link
Copy Markdown

Human comments

What was wrong

Pointerdown already starts GET /threads/:id?include=environment,host (Datahazed/bb#8). Keyboard users who Tab to a sidebar row and press Enter still started that GET after ThreadDetailView mounted. Same first-paint stall, different input.

Related: get-bb/bb#1303.

What changed

  • onFocus on the thread row link calls prefetchThreadDetailBootstrap, the same helper pointerdown and create use.
  • Enter then joins the in-flight bootstrap instead of starting it after mount.

No router change. No daemon bump.

Why this way

Focus is the keyboard analogue of pointerdown: we know the thread id before activation. Hover prefetch is still out — it would fire while scrolling a long list. We did not keep both compose and thread views mounted.

Benefit to bb

Keyboard thread-open matches click: the include GET is already in flight when the detail view mounts. Completes the sidebar-open half of the first-paint rule without a new API.

Harvest

Submit after #8 / get-bb get-bb#2935 so prefetchThreadDetailBootstrap exists. Copy this body onto a get-bb PR that targets a branch containing those, or stack.

How you verified

AGENT GENERATED

Pointerdown already starts the include GET. Enter on a focused row still
waited until after mount. onFocus uses the same prefetch helper.
@Guitaraholic
Guitaraholic merged commit a9b8eba into main Sep 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant