-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CP Stg] Replace ReportScreenIDSetter with useLastAccessedReportID #44559
Conversation
# Conflicts: # src/libs/Navigation/AppNavigator/CENTRAL_PANE_SCREENS.tsx
Tests well on Chrome and Desktop but when I open a report on iOS, I am seeing a continuous loading of the page on iOS and Android. Screen.Recording.2024-06-27.at.11.31.19.PM.movThis issue is not there on |
This comment was marked as outdated.
This comment was marked as outdated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, only NAB comments
Reviewer Checklist
Screenshots/VideosAndroid: NativeScreen.Recording.2024-06-28.at.2.04.18.AM.movAndroid: mWeb ChromeScreen.Recording.2024-06-28.at.2.04.18.AM.moviOS: NativeScreen.Recording.2024-06-28.at.1.59.23.AM.moviOS: mWeb SafariScreen.Recording.2024-06-28.at.2.05.38.AM.movMacOS: Chrome / SafaricenterReportChrome.movMacOS: DesktopcenterReportDesktop.mov |
🧪🧪 Use the links below to test this adhoc build on Android, iOS, Desktop, and Web. Happy testing! 🧪🧪 |
On refreshing the page with Screen.Recording.2024-06-28.at.2.26.23.AM.movIt works fine in the adhoc build. |
@mountiny can you please run the build again now that all changes (hopefully) are done? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests well!
[CP Stg] Replace ReportScreenIDSetter with useLastAccessedReportID (cherry picked from commit 359dbe6)
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
🚀 Cherry-picked to staging by https://github.com/roryabraham in version: 9.0.2-8 🚀
@Expensify/applauseleads please QA this PR and check it off on the deploy checklist if it passes. |
🚀 Deployed to production by https://github.com/jasperhuangg in version: 9.0.3-7 🚀
|
🚀 Deployed to production by https://github.com/Julesssss in version: 9.0.5-13 🚀
|
Details
Some discussion in slack: https://expensify.slack.com/archives/C01GTK53T8Q/p1719427166028799
TL;DR:
navigation
prop in response to user actions. We are usingnavigation.setParams
to set initial params for a screen. The preferred way to do that is withinitialParams
.useLastAccessedReportID
(i.e:useOnyx
/useSyncExternalStore
) and react-navigation mounting the navigator. So in some cases theReportScreen
might fully mount beforeuseLastAccessedReportID
returns the value computed from Onyx. To cover our bases there, we add auseEffect
inReportScreen
that sets thereportID
route param tolastAccessedReportID
if it's not presentReportScreenWrapper
andReportScreenIDSetter
(no-op) components from the view hierarchy.Less TL;DR version:
withOnyx
inReportScreenIDSetter
to calculate thelastAccessedReportID
, and if we did not have a reportID in the URL, we would usenavigation.setParams
to set the reportID tolastAccessedReportID
. The final effect was that we "re-route" fromr/
tor/$lastAccessedReportID
withOnyx
delayed the call tonavigation.setParams
enough that it gave time for the navigation tree to finish mountinguseOnyx
(which usesuseSyncExternalStore
under the hood),ReportScreenIDSetter
became much faster and the render-blocking behavior was removed. As a resultnavigation.setParams
was being called before the navigation tree was finished mounting. This did not work as expected because thereact-navigation
docs assume that you'll be callingnavigate
and/orsetParams
in response to user actions, and after the navigation tree had finished mounting.lastAccessedReportID
up the tree toAuthScreens
{reportID: lastAccessedReportID}
toinitialParams
for theReportScreen
, if there wasn't already a reportID in the routeReportScreenIDSetter
was a no-op component that only contained auseEffect
and returned null. Therefore, we didn't notice (and perhaps it didn't matter) that it would re-render any time any of its Onyx data changes (any report, reportMetadata, policy, etc...). When we moved this toAuthScreens
, it created problems. Not only would this likely have been a performance regression to re-renderAuthScreens
so aggressively, but also it put us in an infinite loop (in the test environment, anyways...)reportMetadata.lastVisitTime
for the reportreportMetadata
changedReportScreen
remounts because the navigator it lives in re-renderedreportMetadata.lastVisitTime
, and we go back to step CuseSyncExternalStore
andOnyx.connect
to subscribe to all the keys needed to computelastAccessedReportID
, and then computes thelastAccessedReportID
property ingetSnapshot
. The result is that even though we still access and respond to all that big Onyx data (reports, reportMetadata, policies, etc...),useLastAccessedReportID
will only trigger a re-render iflastAccessedReportID
changesFixed Issues
$ #44442
PROPOSAL: https://expensify.slack.com/archives/C01GTK53T8Q/p1719506066435689?thread_ts=1719427166.028799&cid=C01GTK53T8Q
Tests / QA Steps
New Chat
pageNext
Offline tests
None - can't refresh the page offline because our site isn't set up with ServiceWorkers.
PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)myBool && <MyComponent />
.src/languages/*
files and using the translation methodSTYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)Design
label and/or tagged@Expensify/design
so the design team can review the changes.ScrollView
component to make it scrollable when more elements are added to the page.main
branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTest
steps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari
web.mov
MacOS: Desktop