Skip to content

[Due for payment 2026-08-08] Derive app skeletons from queued requests #97349

Description

@mountiny

Problem

The initial app skeletons — the inbox sidebar in BaseSidebarScreen and the ForYouSection — decided whether to render from persisted Onyx flags rather than from whether the OpenApp request was actually in flight. BaseSidebarScreen defaulted IS_LOADING_APP to true and tracked "have we ever finished loading" in a module-level variable fed by its own Onyx.connectWithoutView, and ForYouSection gated on isLoadingApp || isLoadingReportData. Because those flags can be stale or optimistically re-set (e.g. ReconnectApp flipping IS_LOADING_REPORT_DATA back to true), the skeletons could show when no app load was pending, or flash again on foreground, reconnect, and tab navigation.

Solution

Both components now derive the initial skeleton from the request queue via the existing useIsAppLoadPending() hook, so the skeleton tracks the real in-flight OpenApp. HAS_LOADED_APP keeps the skeleton limited to the first load (including holding it while that key is still hydrating, checked with isLoadingOnyxValue), and IS_LOADING_APP is demoted to a narrow isColdRestartRecoveryFallback for recovering an interrupted cold start after HAS_LOADED_APP hydrates false. This deletes the module-level hasEverFinishedLoading variable and its ad-hoc Onyx subscription, and the skeleton telemetry reasonAttributes are updated to report the new signals. New UI tests in tests/ui/BaseSidebarScreenTest.tsx and tests/ui/ForYouSectionTest.tsx cover the cold-load, hydrating, and already-loaded cases.

PR

#97115

Issue OwnerCurrent Issue Owner: @BartekObudzinski

Metadata

Metadata

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions