-
-
Notifications
You must be signed in to change notification settings - Fork 5.1k
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
feat: manage unhandled deep link on authentication #10939
feat: manage unhandled deep link on authentication #10939
Conversation
BREAKING CHANGE: Previously, you could specify a route `key` to navigate to, e.g. `navigation.navigate({ key: 'someuniquekey' })`. It's problematic since `key` is an internal implementation detail and created by the library internally - which makes it weird to use. None of the other actions support such usage either. In addition, we have already added a better API (`getId`) which can be used for similar use cases - and gives users full control since they provide the ID and it's not autogenerated by the library. So this change removes the `key` option from the `navigate` action.
`navigate` BREAKING CHANGE: Previously, `navigate` method navigated back if the screen already exists in the stack. I have seen many people get confused by this behavior. This behavior is also used for sending params to a previous screen in the documentation. However, it's also problematic since it could either push or pop the screens based on the scenario. This removes the going back behavior from `navigate` and adds a new method `popTo` to go back to a specific screen in the stack. The methods now behave as follows: - `navigate(screenName)` will stay on the current screen if the screen is already focused, otherwise push a new screen to the stack. - `popTo(screenName)` will go back to the screen if it exists in the stack, otherwise pop the current screen and add this screen to the stack. - To achieve the previous behavior with `navigate`, you can use the `getId` prop in which case it'll go to the screen with the matching ID and push or pop screens accordingly.
BREAKING CHANGE: Previously, the `onReady` prop and `navigationRef.isReady()` work slightly differently. The `onReady` callback fired when `NavigationContainer` finishes mounting and deep links is resolved. The `navigationRef.isReady()` method additionally checks if there are any navigators rendered - which may not be `true` if the user is rendering their navigators conditionally inside a `NavigationContainer`. This changes `onReady` to work similar to `navigationRef.isReady()`. The `onReady` callback will now fire only when there are navigators rendered - reflecting the value of `navigationRef.isReady()`.
BREAKING CHANGE: Previously, you could specify a route `key` to navigate to, e.g. `navigation.navigate({ key: 'someuniquekey' })`. It's problematic since `key` is an internal implementation detail and created by the library internally - which makes it weird to use. None of the other actions support such usage either. In addition, we have already added a better API (`getId`) which can be used for similar use cases - and gives users full control since they provide the ID and it's not autogenerated by the library. So this change removes the `key` option from the `navigate` action.
`navigate` BREAKING CHANGE: Previously, `navigate` method navigated back if the screen already exists in the stack. I have seen many people get confused by this behavior. This behavior is also used for sending params to a previous screen in the documentation. However, it's also problematic since it could either push or pop the screens based on the scenario. This removes the going back behavior from `navigate` and adds a new method `popTo` to go back to a specific screen in the stack. The methods now behave as follows: - `navigate(screenName)` will stay on the current screen if the screen is already focused, otherwise push a new screen to the stack. - `popTo(screenName)` will go back to the screen if it exists in the stack, otherwise pop the current screen and add this screen to the stack. - To achieve the previous behavior with `navigate`, you can use the `getId` prop in which case it'll go to the screen with the matching ID and push or pop screens accordingly.
BREAKING CHANGE: Previously, the `onReady` prop and `navigationRef.isReady()` work slightly differently. The `onReady` callback fired when `NavigationContainer` finishes mounting and deep links is resolved. The `navigationRef.isReady()` method additionally checks if there are any navigators rendered - which may not be `true` if the user is rendering their navigators conditionally inside a `NavigationContainer`. This changes `onReady` to work similar to `navigationRef.isReady()`. The `onReady` callback will now fire only when there are navigators rendered - reflecting the value of `navigationRef.isReady()`.
PR removes deprecation warnings introduced in 8e0ae5f
Due to backward compatibility reasons, React Navigation 5 and 6 support navigating to a screen in a child navigator with `navigation.navigate(ScreenName)` syntax. But this is problematic with the new architecture - it only works if the navigator is already mounted, doesn't work with TypeScript, etc. That's why there's a special API to navigate to a nested screen (`navigation.navigate(ParentScreenName, { screen: ScreenName })`). This drops this behavior and adds a prop to explicitly enable it to make it easier to migrate. This prop will be removed in the next major.
The Expo app for the example from this branch is ready! expo.dev/@react-navigation/react-navigation-example?release-channel=pr-10939 |
BREAKING CHANGE: Previously, you could specify a route `key` to navigate to, e.g. `navigation.navigate({ key: 'someuniquekey' })`. It's problematic since `key` is an internal implementation detail and created by the library internally - which makes it weird to use. None of the other actions support such usage either. In addition, we have already added a better API (`getId`) which can be used for similar use cases - and gives users full control since they provide the ID and it's not autogenerated by the library. So this change removes the `key` option from the `navigate` action.
`navigate` BREAKING CHANGE: Previously, `navigate` method navigated back if the screen already exists in the stack. I have seen many people get confused by this behavior. This behavior is also used for sending params to a previous screen in the documentation. However, it's also problematic since it could either push or pop the screens based on the scenario. This removes the going back behavior from `navigate` and adds a new method `popTo` to go back to a specific screen in the stack. The methods now behave as follows: - `navigate(screenName)` will stay on the current screen if the screen is already focused, otherwise push a new screen to the stack. - `popTo(screenName)` will go back to the screen if it exists in the stack, otherwise pop the current screen and add this screen to the stack. - To achieve the previous behavior with `navigate`, you can use the `getId` prop in which case it'll go to the screen with the matching ID and push or pop screens accordingly.
BREAKING CHANGE: Previously, the `onReady` prop and `navigationRef.isReady()` work slightly differently. The `onReady` callback fired when `NavigationContainer` finishes mounting and deep links is resolved. The `navigationRef.isReady()` method additionally checks if there are any navigators rendered - which may not be `true` if the user is rendering their navigators conditionally inside a `NavigationContainer`. This changes `onReady` to work similar to `navigationRef.isReady()`. The `onReady` callback will now fire only when there are navigators rendered - reflecting the value of `navigationRef.isReady()`.
PR removes deprecation warnings introduced in 8e0ae5f
Due to backward compatibility reasons, React Navigation 5 and 6 support navigating to a screen in a child navigator with `navigation.navigate(ScreenName)` syntax. But this is problematic with the new architecture - it only works if the navigator is already mounted, doesn't work with TypeScript, etc. That's why there's a special API to navigate to a nested screen (`navigation.navigate(ParentScreenName, { screen: ScreenName })`). This drops this behavior and adds a prop to explicitly enable it to make it easier to migrate. This prop will be removed in the next major.
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## 7.x #10939 +/- ##
======================================
Coverage ? 76.07%
======================================
Files ? 172
Lines ? 5175
Branches ? 1996
======================================
Hits ? 3937
Misses ? 1198
Partials ? 40 Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
/rebase |
1b0a943
to
89cde12
Compare
…tc. (#11602) This code is mostly moved changes from #10939. Additionally, I propose a different name and add ability to handle the login in nested navigators **Motivation** This PR implements API for handling deep links with conditional rendering. Refer to [Handle deep link + auth in React Navigation](https://gist.github.com/satya164/af3a6f25c03dfbae9ca72ede19d170bc). **Test plan** To check, open `index.ts` and change the flag `LINKING_EXAMPLE = true` Then, use `xcrun simctl openurl booted exp://127.0.0.1:19000/--/outer/profile` --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Motivation
This PR implements API for handling deep links with conditional rendering described in detail by @satya164 in Handle deep link + auth in React Navigation.
Demo
Before
Default behavior
Screen.Recording.2022-10-20.at.16.42.05.mov
After
With the use of
useLinkingOnConditionalRender
hookwith.useLinkingOnConditionalRender.mov
Test plan
Invoke deep link in Expo Go on iOS:
xcrun simctl openurl booted exp://127.0.0.1:19000/--/profile
Invoke deep link in Expo Go on Android
adb shell am start -W -a android.intent.action.VIEW -d "exp://127.0.0.1:19000/--/profile" host.exp.exponent
Code example