Read cached thread in AppLayout while bootstrap is in flight - #10
Merged
Conversation
#6 painted ThreadDetailView from threadQueryKey. AppLayout still disabled useThread until bootstrap settled, so document title and the favicon attention dot waited on the include GET. useThread now takes the bootstrap snapshot and applies the same mount policy, so layout chrome uses the create/list cache immediately.
Guitaraholic
pushed a commit
that referenced
this pull request
Sep 2, 2026
Guitaraholic
changed the base branch from
fix/thread-paint-from-cache
to
main
September 2, 2026 19:14
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Human comments
What was wrong
Datahazed/bb#6 lets
ThreadDetailViewreadthreadQueryKeywhile bootstrap is in flight.AppLayoutstill disableduseThreaduntilGET /threads/:id?include=environment,hostsettled. After send (or any cached open),document.titlestayedThread <id prefix>and the favicon attention dot could not see the thread until that GET returned.Same cache, second caller. Web and desktop (
apps/app).Related: get-bb/bb#1303.
What changed
useThreadacceptsbootstrapand appliesresolveThreadDetailQueryMountinternally (it already has the QueryClient).ThreadDetailViewandAppLayout(when the route is a thread) pass that snapshot. Non-thread routes keeprefetchOnMount: "always".useThread; they do not need a QueryClient.Stacked on #6. No protocol bump.
Why this way
The helper already existed. The remaining wait was the other
useThreadcall site. Putting the policy insideuseThreadis the one place both the pane and the shell go through, without addinguseQueryClienttoAppLayout(that would break layout tests that have no provider).We did not unify compose+thread, and we did not start
useEnvironmentbefore bootstrap (that would duplicate the include GET).Benefit to bb
Web and desktop. After create or a cached open, the window title and favicon badge match the thread immediately instead of waiting on bootstrap. Same product rule as #6: do not refuse cache we already wrote.
Harvest
Submit after #6 (this branch is stacked on it). Independent of #7/#8. Copy this body.
Decision record: Datahazed/bb#9.
How you verified
The existing phase-order test still records
thread-chrome-readybeforebootstrap-settled, now viauseThread({ bootstrap })— the same path AppLayout uses.apps/app/src/hooks/queries/thread-queries.test.tsx24 passed.AppLayout.plugin-panel-header.test.tsx,AppLayout.root-compose-project.test.tsx,AppLayout.sidebar-resize.test.tsx7 passed.