-
Notifications
You must be signed in to change notification settings - Fork 87
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
fix(profile): register new screens for settings, help, invite #5121
Conversation
src/account/Settings.tsx
Outdated
@@ -435,7 +435,7 @@ export const Account = ({ navigation, route }: Props) => { | |||
} | |||
|
|||
return ( | |||
<SafeAreaView style={styles.container}> | |||
<SafeAreaView style={styles.container} edges={['bottom']}> |
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.
Does edges need to be conditional also?
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5121 +/- ##
==========================================
+ Coverage 85.56% 85.69% +0.12%
==========================================
Files 729 729
Lines 29823 29833 +10
Branches 5144 5154 +10
==========================================
+ Hits 25519 25565 +46
+ Misses 4068 4033 -35
+ Partials 236 235 -1
... and 4 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
1 build increased size
Celo (test) 1.80.0 (145)
|
Item | Install Size Change |
---|---|
main.jsbundle | ⬆️ 4.1 kB |
🛸 Powered by Emerge Tools
src/backup/BackupComplete.tsx
Outdated
navigate( | ||
getFeatureGate(StatsigFeatureGates.USE_TAB_NAVIGATOR) | ||
? Screens.Settings | ||
: Screens.SettingsDrawer, |
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 believe this will lead to a crash if a feature gate changes when the app is backgrounded. Can you test the follow scenario?
- Have the feature on for your wallet, navigate to this screen (or any of the below screens)
- Background the app
- Change your wallet to be on the false variant and give a few mins for things to be updated
- Foreground the app and invoke the action to go to settings
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.
@satish-ravi you're right, I get this error when following this procedure to go back to settings. Is there a way to do navigate to make sure the screens are available, or should it just navigate home?
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.
you can navigate to Screens.DrawerNavigator with initial screen name as Screens.SettingsDrawer, there should be examples of others.
src/backup/BackupComplete.tsx
Outdated
navigate(Screens.Settings, { promptConfirmRemovalModal: true }) | ||
navigate( | ||
getFeatureGate(StatsigFeatureGates.USE_TAB_NAVIGATOR) | ||
? Screens.Settings |
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.
Wonder if we have to clear the stack before navigating to the new settings screen with back. Previously we landed back on the drawer and there was no way for the user to go back, but wonder if this opens up the possibility on landing on an inconsistent state in the app.
src/pincode/PincodeSet.test.tsx
Outdated
@@ -166,7 +166,7 @@ describe('Pincode', () => { | |||
}) | |||
|
|||
expect(updatePin).toHaveBeenCalledWith(mockAccount.toLowerCase(), oldPin, mockPin) | |||
expect(navigate).toBeCalledWith(Screens.Settings) | |||
expect(navigate).toBeCalledWith(Screens.SettingsDrawer) |
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.
better to switch any test that checks settings navigation to run against the true
variant (or test both scenarios). Might also be worth wrapping navigating to settings into a helper function given my comments above. I don't think it will be as simple as navigating one or the other screen
src/navigator/NavigationService.ts
Outdated
@@ -231,6 +231,12 @@ export function navigateHome(fromModal?: boolean) { | |||
}, timeout) | |||
} | |||
|
|||
export function navigateToSettings(promptConfirmRemovalModal: boolean) { | |||
getFeatureGate(StatsigFeatureGates.USE_TAB_NAVIGATOR) | |||
? navigateClearingStack(Screens.Settings, { promptConfirmRemovalModal }) |
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.
actually would the user get stuck on the settings screen here? this would reset settings to the first screen. wonder if we should just navigate home, although not sure if it will break stuff. Maybe good to check in with product as well
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.
yeah I was thinking of just navigating to home, I'll check with product and see
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 synced with Laura on this and we don't want to navigate home instead of settings in most places. Seems like there's only a handful of places where we navigate to settings. So let's do this:
- change keyless backup progress screen to navigate home instead of settings (as the flow can start from either settings or notifications screen)
- to solve the edge case of feature gate changing when the user is on the Settings screen and backgrounded, I think we can get away with using the same screen enum. If we do that, then the version of settings screen that the flow started with will already be on the stack, so any
navigate(Screen.Settings)
would just pop back to that screen, instead of adding the new version of the screen to the stack. This should work as long as there is no flow that starts from somewhere else in the app and ends in settings, which I believe is only the keyless backup progress screen which we've addressed above.
src/navigator/Navigator.tsx
Outdated
<Navigator.Screen | ||
name={Screens.Settings} | ||
component={SettingsScreen} | ||
options={isTabNav ? headerWithBackButton : noHeader} |
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.
could we just register the back button always? I think this version of the screen should only be used in the tab navigator anyway. The screens I believe are registered at startup and won't be refreshed if the gate changes when app is backgrounded.
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.
@finnian0826 Thanks for working to getting this across the finish line! 🚀
src/backup/BackupQuiz.tsx
Outdated
return navigatedFromSettings ? ( | ||
<CancelButton onCancel={onCancel} style={styles.cancelButton} /> | ||
return settingsScreen ? ( | ||
<CancelButton onCancel={() => navigateHome()} /> |
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.
probably fine to go home here but the settingsScreen param now allows us to retain existing behavior right? We can navigate similar to what is done in BackupComplete?
src/backup/BackupQuiz.tsx
Outdated
cancelButton: { | ||
color: colors.gray4, | ||
}, |
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.
same question as above
return ( | ||
<SafeAreaView style={styles.container}> | ||
<CustomHeader | ||
style={{ paddingHorizontal: variables.contentPadding }} | ||
left={ | ||
navigatedFromSettings ? ( | ||
<CancelButton style={styles.cancelButton} /> |
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.
seems like this was just navigating back previously ? could we retain the same behavior here?
src/backup/BackupPhrase.tsx
Outdated
cancelButton: { | ||
color: colors.gray4, | ||
}, |
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.
any reason to remove this styling?
const backupCompleted = useSelector(backupCompletedSelector) | ||
const { t } = useTranslation() | ||
|
||
useEffect(() => { | ||
const timer = setTimeout(() => { | ||
if (navigatedFromSettings) { | ||
navigate(Screens.Settings, { promptConfirmRemovalModal: true }) | ||
if (settingsScreen) { |
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.
might be worth leaving a cleanup comment here. I liked your naming on isAccountRemoval
, maybe we can do that when we clean the drawer ? Should be also fine to just describe this in the linear issue @MuckT created.
…-inc#5121) ### Description Registers new screens and modifies headers so can navigate back. ### Test plan Unit tests updated. **Manual tests:** Feature gate false: https://github.com/valora-inc/wallet/assets/140328381/74b676ea-334a-4c49-ae17-f868ac98b776 Feature gate true: https://github.com/valora-inc/wallet/assets/140328381/91ded2a7-d54f-43a8-8f65-a33ac8a3fbaf ### Related issues - Fixes ACT-1132 ### Backwards compatibility <!-- Brief explanation of why these changes are/are not backwards compatible. --> ### Network scalability If a new NetworkId and/or Network are added in the future, the changes in this PR will: - N/A --------- Co-authored-by: Tom McGuire <Mcgtom10@gmail.com> Co-authored-by: Satish Ravi <satish.ravi@valoraapp.com>
…inc#5336) ### Description Reverts changes done in valora-inc#5121 , can just pass a boolean to the that there's a single Settings screen ### Test plan CI, manually trying reset ### Related issues - Part of ACT-1133 ### Backwards compatibility Yes ### Network scalability N/A
Description
Registers new screens and modifies headers so can navigate back.
Test plan
Unit tests updated.
Manual tests:
Feature gate false:
old.mp4
Feature gate true:
new.mp4
Related issues
Backwards compatibility
Network scalability
If a new NetworkId and/or Network are added in the future, the changes in this PR will: