fix: Skeleton is displayed when create offline Room in focus mode and switch#54180
fix: Skeleton is displayed when create offline Room in focus mode and switch#54180lakchote merged 6 commits intoExpensify:mainfrom
Conversation
Reviewer Checklist
Screenshots/VideosAndroid: Nativeandroid-app-2024-12-16_14.57.08.mp4Android: mWeb Chromeandroid-chrome-2024-12-16_14.59.08.mp4iOS: Nativeios-app-2024-12-16_15.05.49.mp4iOS: mWeb Safariios-safari-2024-12-16_15.10.50.mp4MacOS: Chrome / Safaridesktop-chrome-2024-12-16_14.51.36.mp4MacOS: Desktopdesktop-app-2024-12-16_14.54.18.mp4 |
src/libs/actions/Report.ts
Outdated
| value: {isLoading: false}, | ||
| }, | ||
| { | ||
| onyxMethod: Onyx.METHOD.MERGE, |
There was a problem hiding this comment.
This is duplicate code of the above section. But I think we do want it in the failureData as isOptimisticReport should always clear.
There was a problem hiding this comment.
I added the isOptimisticReport: false to failureData.
There was a problem hiding this comment.
Do you see that we already have this code above though?
App/src/libs/actions/Report.ts
Lines 2376 to 2380 in 83267e2
src/pages/home/ReportScreen.tsx
Outdated
| // eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing | ||
| (deleteTransactionNavigateBackUrl && ReportUtils.getReportIDFromLink(deleteTransactionNavigateBackUrl) === report?.reportID) || | ||
| isLoading; | ||
| ((!ReportUtils.isUserCreatedPolicyRoom(report) || !reportMetadata.isOptimisticReport) && isLoading); |
There was a problem hiding this comment.
Hmm now that I think about it this feels a bit hacky. Is there any reason to specifically apply this to policy rooms?
I've also noticed whilst testing that isLoadingApp gets set to true only when the mode is switched to Most recent (not to #focus), which makes me think that we may have actually missed the true RCA here. I think isLoadingApp is either being incorrectly set when the focus mode is switched, or this is an unexpected side-effect of it.
There was a problem hiding this comment.
A similar behaviour happens on any existing report, where if you switch specifically from #focus to Most recent, only the most recent message loads, the rest are in a loading state.
There was a problem hiding this comment.
Hmm now that I think about it this feels a bit hacky. Is there any reason to specifically apply this to policy rooms?
- I just want to ensure this change doesn’t unintentionally affect other report types I might not have context on. It’s important to verify these also work correctly with the new change.
I've also noticed whilst testing that isLoadingApp gets set to true only when the mode is switched to Most recent (not to #focus), which makes me think that we may have actually missed the true RCA here. I think isLoadingApp is either being incorrectly set when the focus mode is switched, or this is an unexpected side-effect of it.
- When switching from focus mode to default mode, we call openApp():
Lines 75 to 78 in d86024e
As a result, isLoadingApp gets set to true.
A similar behavior happens on any existing report, where if you switch specifically from #focus to Most recent, only the most recent message loads, the rest are in a loading state.
- I see your point. However, for existing reports, we show the loading indicator because we don’t know “how many actions are missing” when switching from focus mode to default mode. In the case of an optimistic report, though, we can confidently determine that “no fetch is needed,” as explained here:
App/src/libs/shouldFetchReport.ts
Line 7 in d86024e
There was a problem hiding this comment.
I just want to ensure this change doesn’t unintentionally affect other report types I might not have context on. It’s important to verify these also work correctly with the new change.
Makes sense, limiting the scope can reduce the chance for regressions. Are we okay to just focus on rooms here @lakchote, or do you think we should fix other reports (e.g. group chats)?
However, for existing reports, we show the loading indicator because we don’t know “how many actions are missing”
Okay, just gonna check on Slack regarding the expected behaviour there to make sure.
There was a problem hiding this comment.
I'd say we need to fix the whole issue as a whole and fix this for other reports.
If this introduces potential side effects/regressions, then we'll need to fix it and that would indicate the RCA of the solution here wasn't the correct one. I'd prefer to have solved the root cause and not a possibly hack that works for certain report types.
There was a problem hiding this comment.
Okay gotcha - let's do it for all report types, then - unless you disagree @truph01.
jjcoffee
left a comment
There was a problem hiding this comment.
LGTM! Confirmed that it works with other chat types, e.g. group chat.
|
All yours @lakchote 🙏 |
|
Thank you both for your work! |
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
|
🚀 Deployed to staging by https://github.com/lakchote in version: 9.0.81-0 🚀
|
|
@izarutskaya I cannot reproduce the bug in IOS safari, staging: https://staging.new.expensify.com/ @jjcoffee Can you reproduce it? |
|
🚀 Deployed to production by https://github.com/puneetlath in version: 9.0.81-6 🚀
|
|
Hmm yeah I also couldn't repro. |
Explanation of Change
Fixed Issues
$ #53660
PROPOSAL: #53660 (comment)
Tests
Offline tests
QA Steps
// TODO: These must be filled out, or the issue title must include "[No QA]."
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
output.mp4
Android: mWeb Chrome
Screen.Recording.2024-12-16.at.15.26.56.mov
iOS: Native
Screen.Recording.2024-12-16.at.15.30.45.mov
iOS: mWeb Safari
Screen.Recording.2024-12-16.at.15.32.31.mov
MacOS: Chrome / Safari
Screen.Recording.2024-12-16.at.15.17.27.mov
MacOS: Desktop
Screen.Recording.2024-12-16.at.15.34.29.mov