-
Notifications
You must be signed in to change notification settings - Fork 3k
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
[TS migration] Migrate 'Navigation' lib to TypeScript #31543
[TS migration] Migrate 'Navigation' lib to TypeScript #31543
Conversation
Thanks for the reminder. I will ask for help since I am not available to review today |
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.
Thanks for working on this big PR
@situchan Thank you for the detailed review from your side! Adjusted the code 🚀 |
BUG: infinite loading on report screen on desktop app when opened from deeplink Screen.Recording.2023-11-24.at.10.09.51.PM.movI will confirm if this also happens on main |
I didn't know how to test deep links on desktop 😅 - for me the browser was always opened instead.. If it is only reproduced on this branch please describe the reproduction steps precisely. |
Confirmed happening on main as well so not blocker.
Please comment this line to test desktop deeplinking: App/src/components/DeeplinkWrapper/index.website.js Lines 72 to 74 in e355608
|
Reviewer Checklist
Screenshots/VideosAndroid: Nativeandroid.movAndroid: mWeb Chromemchrome.moviOS: Nativeios.moviOS: mWeb Safarimsafari.movMacOS: Chrome / Safariweb.movMacOS: Desktopdesktop.mov |
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.
function getUrlWithBackToParam(url: string, backTo?: string): string { | ||
const backToParam = backTo ? `${url.includes('?') ? '&' : '?'}backTo=${encodeURIComponent(backTo)}` : ''; | ||
return url + backToParam; | ||
function getUrlWithBackToParam<TUrl extends string>(url: TUrl, backTo?: string): `${TUrl}` | `${TUrl}?backTo=${string}` | `${TUrl}&backTo=${string}` { |
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.
Not exactly sure how one would accomplish this, but I feel like a utility type for urls would be helpful, such that you could provide:
- a base URL
- an object type representing a series of optional or required query params (which of course can be in any order)
And then the resultant type would be any string matching the pattern of a valid URL with the correct base and query params.
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.
I feel like it should be doable @roryabraham, but I believe it's not something that should be handled in this PR, for two reasons:
- Preferably JS logic should be untouched in TS migration PRs
- This PR is a high prio for SWM team, as we are working on the navigation refactor. This migration could speed up things 😄
Same as here, would you mind creating an issue for this, so it could be worked on in a separate PR?
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.
please comment for assignment: #32143
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.
just submitted a proposal for #32143
@roryabraham
|
||
type SettingsNavigatorParamList = { | ||
[SCREENS.SETTINGS.ROOT]: undefined; | ||
Settings_Share_Code: undefined; |
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.
NAB but I think now is as good a time as any to standardize on always using constants for screen names. I don't like how we have two patterns for defining screen names, as I think it causes confusion when adding new screens or when adding a new constant for a screen name.
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.
I would love to work on this, would you be able to create an issue for this so I can do it in a separate PR? @roryabraham
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.
Comment for assignment: #32141
@@ -0,0 +1,401 @@ | |||
/* eslint-disable @typescript-eslint/naming-convention */ | |||
import {CommonActions, NavigationContainerRefWithCurrent, NavigationHelpers, NavigationState, NavigatorScreenParams, PartialRoute, Route} from '@react-navigation/native'; |
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.
This file overall seems like a lot of duplication. Are you sure we can't derive these types, or is it better to define them separately in case of platform fragmentation?
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.
What part exactly?
- Lines 36-399 is just definition for screens params,
- Lines 12-34 is something that I had to extract from react navigation because of how we use navigation in the App. I don't think we can remove that part.
- Lines 8-10 is kind of redundant but helpful imo.
@roryabraham thanks for reviewing this, as it seems like you're handling it I'll remove my request for review. |
I think @roryabraham is OOO after Thanksgiving (based on Rory's Slack status). @flodnv could you handle review instead? Thank you in advance 😄 |
Looks like he'll be back today
…On Tue, Nov 28, 2023 at 4:45 AM Błażej Kustra ***@***.***> wrote:
I think @roryabraham <https://github.com/roryabraham> is OOO after
Thanksgiving (based on Rory's Slack status). @flodnv
<https://github.com/flodnv> could you handle review instead? Thank you in
advance 😄
—
Reply to this email directly, view it on GitHub
<#31543 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA7Y2OJ4DMOANBVBA6OWA63YGWQCBAVCNFSM6AAAAAA7SZ3SS6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRZGM2TCMZZHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
✋ 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 production by https://github.com/mountiny in version: 1.4.5-7 🚀
|
Details
Migration of
Navigation
to Typescript.Fixed Issues
$ #24934
PROPOSAL: N/A
Tests
Offline tests
N/A
QA Steps
Same as Tests
PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)myBool && <MyComponent />
.src/languages/*
files and using the translation methodWaiting for Copy
label for a copy review on the original GH to get the correct copy.STYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)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.1.webm
Android: mWeb Chrome
android-web.webm
iOS: Native
ios.mp4
iOS: mWeb Safari
ios-web.mp4
MacOS: Chrome / Safari
web.mov
MacOS: Desktop
desktop.mov