Fix defaultFullScreenRoute in getAdaptedState - #81690
Conversation
f54fda7 to
e2e92e4
Compare
|
@ZhenjaHorbach Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
|
✅ Code Review Complete I've reviewed the changes in this PR and found no rule violations. SummaryThe simplification of
The code follows best practices and improves maintainability. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e2e92e4fed
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| const fallbackRoute = {name: SCREENS.HOME}; | ||
| if (route && isRouteWithReportID(route)) { | ||
| const reportID = route.params.reportID; | ||
|
|
There was a problem hiding this comment.
Keep report deep links off Home when report data is cold
When a deep link targets a report-related RHP screen, getDefaultFullScreenRoute only builds the split navigator if the report is already in Onyx. On cold start, allReports is typically empty, so this now falls back to SCREENS.HOME instead of the reports split navigator. That means the overlay is rendered over Home and closing it leaves the user on Home rather than Inbox/report, which is a regression for logged-in report flows. This only happens when the route has reportID but Onyx isn’t hydrated yet.
Useful? React with 👍 / 👎.
Codecov Report❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.
|
e2e92e4 to
98b8b3a
Compare
Reviewer Checklist
Screenshots/VideosAndroid: HybridApp2026-02-06.18.42.43.movAndroid: mWeb Chrome2026-02-06.18.28.16.moviOS: HybridApp2026-02-06.18.42.43.moviOS: mWeb Safari2026-02-06.18.28.16.movMacOS: Chrome / Safari2026-02-06.18.26.08.mov |
|
No product review needed |
|
After onboarding, I navigated to the accounts screen for some reason on ios web 2026-02-06.18.28.16.mov |
|
@ZhenjaHorbach I tried to reproduce that, but it seems to work fine. Screen.Recording.2026-02-09.at.10.37.23.movDoes this always happen or just sometimes? |
|
Just rechecked |
|
LGTM! |
|
🚧 @grgia has triggered a test Expensify/App build. You can view the workflow run here. |
|
🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
|
|
🚀 Deployed to staging by https://github.com/grgia in version: 9.3.16-0 🚀
|
|
🚀 Deployed to production by https://github.com/lakchote in version: 9.3.16-9 🚀
|
Explanation of Change
In
getAdaptedStateFromPath, thegetDefaultFullScreenRoutelogic was simplified so that:Fallback route is always
SCREENS.HOME: Previously it usedSCREENS.HOMEonly for public screens andNAVIGATORS.REPORTS_SPLIT_NAVIGATORotherwise; now it unconditionally setsfallbackRoute = {name: SCREENS.HOME}before applying the existing reportID-based logic.Fixed Issues
$ #81523
PROPOSAL:
Tests
Offline tests
QA Steps
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectioncanBeMissingparam foruseOnyxtoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)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
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari