-
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
Android - Deeplink navigation does not work for RHN links. #28278
Android - Deeplink navigation does not work for RHN links. #28278
Conversation
@narefyev91 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] |
Reviewer Checklist
Screenshots/VideosWebweb.movMobile Web - Chromeandroid-web.movMobile Web - Safariios-web.movDesktopdesktop.moviOSios.movAndroidandroid.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.
LGMT!
🎀 👀 🎀 C+ reviewed
We did not find an internal engineer to review this PR, trying to assign a random engineer to #27168 as well as to this PR... Please reach out for help on Slack if no one gets assigned! |
@lukemorawski please re-base from main branch - jest unit tests 3 was fixed on main |
@narefyev91 rebased! |
(Yuwen is OOO, I'll take over this on his behalf) Looks like there's a small conflict, can you resolve it so we can merge please @lukemorawski? |
@francoisl Sorry, I was ooo yesterday. Will resolve 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.
cc @thienlnam FYI - I'm just seeing Yuwen had reassigned you to the issue
src/libs/Navigation/Navigation.js
Outdated
* Waits for the navigation state to contain protected routes (specifically 'Concierge'). | ||
* If the navigation is in a state, where protected routes are available, the promise will resolve immediately. |
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 to make sure I understand, is "protected route" a new concept we're introducing? I'm not sure I understand what it has to do with Concierge specifically.
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.
nope, it's just the way routes hidden behind the auth process are called. Since Concierge is the one of the most important screens that is available to users after logging in, I'm using it to detect the change and readiness of the navigation state. In simple words - when Concierge is present as one of the available routes in the nav state, this means that app is showing protected routes.
Main cause of the whole bug was, that the app was trying to navigate to a protected route immediately after logging in, but the navigation was not ready yet and it was throwing an error.
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.
Is there another way we can wait for navigation to finish? I'm not sure I like the idea of checking if Concierge is an available route before allowing navigation. There might be situations in the future where the Concierge route is not available (I.e anonymous accounts)
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 understand, though with current nav setup it's hard to come up with a better way. If the navigation was done using protected route guard components, that would be easier (or even unnecessary), but there's a conditional nav tree rendering in <AppNavigator />
component and the nav state is not immediately following the rendering state. The other way around this problem would be to introduce some global (app wide) state, a flag perhaps, that would indicate the readiness of the nav tree. This would require every protected page, and every public page to update this flag on it's mounting. So when a protected page (screen) is loaded then it updates this new flag to, lets say true, and when a public screen is loaded it updates this flag to false. But that requires a lot of additional code all over the app. That would be the most robust approach I guess.
The other would be to create a separate const of protected routes, that would be spreaded to the const of other screens in the SCREENS.ts
, but it's a bit more tricky. Currently checking that option.
src/libs/Navigation/Navigation.js
Outdated
* Waits for the navigation state to contain protected routes (specifically 'Concierge'). | ||
* If the navigation is in a state, where protected routes are available, the promise will resolve immediately. |
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.
Is there another way we can wait for navigation to finish? I'm not sure I like the idea of checking if Concierge is an available route before allowing navigation. There might be situations in the future where the Concierge route is not available (I.e anonymous accounts)
@thienlnam I've improved a bit the way to recognise the navigation has transitioned to the authorised state. Instead of checking if |
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, I like this solution more than just checking Concierge - looks like just the comments are now slightly outdated but rest looks good
src/libs/Navigation/Navigation.js
Outdated
} | ||
|
||
/** | ||
* Waits for the navigation state to contain protected routes (specifically 'Concierge'). |
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.
Comments need to be updated now
@thienlnam Fixed the comment! |
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.
Great, thanks!
✋ 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/thienlnam in version: 1.3.84-0 🚀
|
🚀 Deployed to production by https://github.com/francoisl in version: 1.3.84-10 🚀
|
🚀 Deployed to production by https://github.com/francoisl in version: 1.3.84-10 🚀
|
🚀 Deployed to staging by https://github.com/thienlnam in version: 1.3.85-0 🚀
|
🚀 Deployed to production by https://github.com/francoisl in version: 1.3.85-4 🚀
|
Details
This PR addresses the issue of unhandled deep links invoked when the app is in the unauthenticated state.
Even though the app was defering navigation to the deep link route until the user is authenticated, that still was not enough.
Turns out that immediately after the auth flag changes, the nav tree is not done rebuilding and the protected routes are not yet available for navigation.
To address that issue, the app now waits not only for user to log in, but also for the nav state to contain protected routes to continue with the deffered navigation action.
This is done using a dedicated helper function that returns a promise that resolves when the navigation state reaches desired state.
Fixed Issues
$ #27168
PROPOSAL: no proposal
Tests
Offline tests
QA Steps
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)/** comment above it */
this
properly so there are no scoping issues (i.e. foronClick={this.submit}
the methodthis.submit
should be bound tothis
in the constructor)this
are necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);
ifthis.submit
is never passed to a component event handler likeonClick
)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
Web
web.desktop.mov
Mobile Web - Chrome
web.android.mov
Mobile Web - Safari
web.ios.mov
Desktop
web.desktop.mov
iOS
native.ios.mov
Android
native.android.mov