On this screen a user can provide their credentials in order to restore their account.
Depends on D13907
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Comment Actions
This screen differs from the log out modal in two ways:
- It doesn't handle setActiveAlert. This function is called by the LogInPanel when an alert is shown. On the logged out modal side, this call results in setting a state that is then used when computing the keyboard height, that is used to determine a panel padding. On this screen we don't need to care about the keyboard height because we don't show a panel that has a position depending on the keyboard height.
- In the logged out modal, we're handling dismissing the LogInPanel by removing a password and adding it again. We do that because otherwise iOS would show a user an alert about saving the password. We can use this trick there because, in reality, we're staying on the same screen, so all the state can be kept. On this screen, we can't do that, and going back might result in the screen being unmounted. This means that showing this alert might be desirable.
Comment Actions
The design here doesn't look great to me... it feels like we're taking the "design language" of LoggedOutModal and applying it in a place where we're mostly using the RegistrationNavigator "design language".
Can we instead try to base the design on RegistrationNavigator? I think we can keep the general structure here (one username field, one password field, and a button), but instead:
- Look at UsernameSelection to get an idea of how to style the username input field.
- Look at PasswordSelection to get an idea of how to style the password input field.
- Use PrimaryButton for the sign-in button.
If we do this, then after launching signed device lists we can probably totally deprecate LogInPanel. What do you think?