Skip to content

Derive report skeletons from queued requests #97350

Description

@mountiny

Problem

Report-level skeletons decided whether to render from the persisted isLoadingInitialReportActions field on the RAM-only report loading state rather than from whether the report's OpenReport request was actually in flight. useReportActionsListModel and shouldWaitForTransactions both read that stored flag, so a value left set after a reload, a response that never cleared it, or a request for a different report could keep a report showing its initial skeleton — or show one when nothing was loading.

Solution

Thread an isReportLoadPending prop, derived from the report-scoped OpenReport queue hook (the request plus its deferred updates), down through ReportActionsSkeletonGuard into useReportActionsListModel and shouldWaitForTransactions, replacing every read of isLoadingInitialReportActions. The stored report loading state is still used for what it is reliable at — list positioning, guards, pagination, and hasOnceLoadedReportActions success tracking, now read through a dedicated hasOnceLoadedReportActionsSelector so the hook only re-renders on that field. Because the skeleton is keyed to this report's own pending request, another report's OpenReport no longer triggers the current report's skeleton, and a terminal failure releases it.

PR

#97116

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