Skip to content

Fix skeleton loader flash on Inbox Unread/To-dos tabs when receiving a message#93533

Draft
MelvinBot wants to merge 1 commit into
mainfrom
claude-fixUnreadSkeletonFlash
Draft

Fix skeleton loader flash on Inbox Unread/To-dos tabs when receiving a message#93533
MelvinBot wants to merge 1 commit into
mainfrom
claude-fixUnreadSkeletonFlash

Conversation

@MelvinBot

Copy link
Copy Markdown
Contributor

Explanation of Change

On the Inbox Unread / To-dos tabs, a brief skeleton loader + empty-state flash appeared whenever a new message arrived (DeployBlockerCash from #92146).

There are two independent skeletons in the Inbox sidebar:

  1. BaseSidebarScreen — the cold-load skeleton, correctly guarded by a module-level hasEverFinishedLoading flag so it is shown only once on first load and never again, even when isLoadingApp briefly flips back to true during a reconnect.
  2. SidebarLinks — a second, unguarded skeleton that rendered whenever isLoadingReportData && optionListItems.length === 0.

PR #92146 changed optionListItems from the full report list to the filtered tab list (SidebarLinksData now passes filteredReports). On the Unread/To-dos tabs that list is legitimately empty when there's nothing to show, so the second condition was constantly satisfied. When a new message arrived, a partial ReconnectApp flipped isLoadingReportData to true while the filtered list was momentarily still empty — so the unguarded SidebarLinks skeleton painted on top of the empty state until the new report synced.

Because BaseSidebarScreen only mounts SidebarLinksData after the first load completes (and already owns the cold-load skeleton with the proper guard), the inner SidebarLinks skeleton could effectively only ever fire in this reconnect-flash scenario. This PR removes that now-redundant skeleton (and its now-unused imports/variables). The "You're all caught up" empty state still renders correctly underneath while the incoming chat streams in — with no skeleton flash.

Fixed Issues

$ #93531
PROPOSAL: #93531 (comment)

Tests

// TODO: The human co-author must fill out the tests you ran before marking this PR as "ready for review"

Suggested manual test:

  1. As User A, ensure there is no existing conversation with User B and no unread chats.
  2. Open the Inbox and switch to the Unread tab (shows "You're all caught up").
  3. From another device/account (User B), start a conversation with User A and send a message.
  4. Verify the new chat appears in the Unread list without a skeleton loader flashing over the empty state.
  5. Regression: cold-launch the app and verify the initial sidebar skeleton still shows once while loading, then the chat list renders.
  • Verify that no errors appear in the JS console

Offline tests

N/A — change only removes a transient loading overlay.

QA Steps

// TODO: The human co-author must fill out the QA tests you ran before marking this PR as "ready for review".

  • Verify that no errors appear in the JS console

PR Author Checklist

  • I linked the correct issue in the ### Fixed Issues section above
  • I wrote clear testing steps that cover the changes made in this PR
    • I added steps for local testing in the Tests section
    • I added steps for the expected offline behavior in the Offline steps section
    • I added steps for Staging and/or Production testing in the QA steps section
    • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
    • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
  • I included screenshots or videos for tests on all platforms
  • I ran the tests on all platforms & verified they passed on:
    • Android: Native
    • Android: mWeb Chrome
    • iOS: Native
    • iOS: mWeb Safari
    • MacOS: Chrome / Safari
  • I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
  • I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App
  • If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari

🤖 Generated by MelvinBot from the approved proposal on #93531. AI checks run locally: lint-changed ✅, prettier ✅, react-compiler check (no regression vs main — file was already in the non-compiling set) ✅, SidebarTest ✅, UnreadIndicatorsTest ✅. typecheck surfaced only pre-existing, unrelated errors in src/libs/API/types.ts (untouched by this PR).

…ects

Co-authored-by: Youssef Lourayad <youssef-lr@users.noreply.github.com>
@github-actions

Copy link
Copy Markdown
Contributor

🚧 @youssef-lr has triggered a test Expensify/App build. You can view the workflow run here.

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.

2 participants