Add helper functions in getMatchingCentralPaneRouteForState#36397
Conversation
|
@thesahindia 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] |
|
@cubuspl42 -> #35613 (comment) |
| return ''; | ||
| }; | ||
|
|
||
| // Function that checks if the given route has a policyID equal to the id provided in the function params |
There was a problem hiding this comment.
When commenting functions, we don't focus on the fact that they're functions. We either write "Do something such and such" or "Does something and something".
| // If one of the screen from WORKSPACES_SCREENS is now in the navigation state, we can decide which screen we should display. | ||
| // A screen from the navigation state can be pushed to the navigation state again only if it has a matching policyID with the currently selected workspace. | ||
| // Otherwise, when we switch the workspace, we want to display the initial screen in the settings tab. | ||
| const WORKSPACES_SCREENS = TAB_TO_CENTRAL_PANE_MAPPING[SCREENS.WORKSPACE.INITIAL].concat(TAB_TO_CENTRAL_PANE_MAPPING[SCREENS.ALL_SETTINGS]); |
There was a problem hiding this comment.
All local variables in the project are named using lower camel case convention.
There was a problem hiding this comment.
But why is this local, if this doesn't depend on function arguments?
| route?.params && | ||
| 'params' in route?.params && | ||
| route.params.params && | ||
| 'policyID' in (route.params.params as Record<string, string | undefined>) && |
There was a problem hiding this comment.
Please don't type assert this twice, extract a local variable of desired target type.
| const WORKSPACES_SCREENS = TAB_TO_CENTRAL_PANE_MAPPING[SCREENS.WORKSPACE.INITIAL].concat(TAB_TO_CENTRAL_PANE_MAPPING[SCREENS.ALL_SETTINGS]); | ||
|
|
||
| const alreadyOpenedSettingsTab = rootState.routes | ||
| .filter((item) => item.params && 'screen' in item.params && WORKSPACES_SCREENS.includes(item.params.screen as keyof CentralPaneNavigatorParamList)) |
There was a problem hiding this comment.
There's a lot of type assertion going on (here and in other places). I gave it a quick look and I couldn't come up with any quick fixes. Do you have any ideas how we could at least reduce the number of type assertions (something as SomeType)?
There was a problem hiding this comment.
Hmm, I am trying to figure it out, but it's not easy because the screen is unknown and when we want to use this variable we need to have a type for it. I'll try to solve it somehow, but I don't know if we can avoid using type assertions here. Could you take a look at the latest update in this PR? It should resolve the comments above :)
Reviewer Checklist
Screenshots/VideosAndroid: NativeAndroid: mWeb ChromeiOS: NativeiOS: mWeb SafariMacOS: Chrome / Safarigo-back-to-settings-page-web-converted.mp4MacOS: Desktopgo-back-to-settings-page-desktop-converted.mp4 |
jakub-trzebiatowski
left a comment
There was a problem hiding this comment.
I also checked Native/mWeb, and they seem to be unaffected, as expected.
hayata-suenaga
left a comment
There was a problem hiding this comment.
thanks everyone for great 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. |
situchan
left a comment
There was a problem hiding this comment.
Please consider this potential regression: #36162 (comment)
|
@cubuspl42 could you check if the regression situchan linked is reproducible and was caused by this PR? |
src/libs/Navigation/linkingConfig/getMatchingCentralPaneRouteForState.ts
Show resolved
Hide resolved
|
🚀 Deployed to staging by https://github.com/hayata-suenaga in version: 1.4.44-0 🚀
|
|
🚀 Deployed to production by https://github.com/puneetlath in version: 1.4.44-13 🚀
|
Details
This PR fixes the issue that appears when we change the selected screen in the settings tab, switch to the chat tab and return to the settings. Then in this tab we should see the previously opened screen, but currently the Profile screen here is always displayed as the initial one.
Fixed Issues
$ #35613
PROPOSAL: N/A
Tests
Offline tests
N/A
QA Steps
Same as tests.
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)myBool && <MyComponent />.src/languages/*files and using the translation methodWaiting for Copylabel for a copy review on the original GH to get the correct copy.STYLE.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 so 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
This issue doesn't occur on the small screen size, so the videos are attached only for:
MacOS: Chrome / SafariMacOS: DesktopMacOS: Chrome / Safari
Screen.Recording.2024-02-13.at.13.08.14.mov
MacOS: Desktop
Screen.Recording.2024-02-13.at.13.10.23.mov