-
Notifications
You must be signed in to change notification settings - Fork 318
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
Improve Confirm Password Error Validation #858
Conversation
🦋 Changeset detectedLatest commit: 86533e8 The changes in this PR will be included in the next version bump. This PR includes changesets to release 4 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
public onBlur($event: Event) { | ||
let { name } = <HTMLInputElement>$event.target; | ||
|
||
this.authenticator.updateForm({ name: `touched_${name}`, value: true }); |
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.
Now we can track the touched elements in the form with the name touched_password
or touched_confirm_password
@@ -16,6 +16,7 @@ export class PasswordFieldComponent { | |||
@Input() placeholder = ''; | |||
@Input() required = true; | |||
@Input() labelHidden = false; | |||
@Output() onBlur = new EventEmitter<Event>(); |
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 could have been an Input()
or Output()
. I felt Output worked here so I left it
@@ -33,5 +33,5 @@ When( | |||
); | |||
|
|||
When('I type my password', () => { | |||
cy.findInputField('Password').type(Cypress.env('VALID_PASSWORD')); | |||
cy.findInputField('Password').type(Cypress.env('VALID_PASSWORD')).blur(); |
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.
Tests were failing unless I added blur
here.
This pull request fixes 7 alerts when merging 6c4da2f into b555532 - view on LGTM.com fixed alerts:
|
This pull request fixes 7 alerts when merging 24331fb into b555532 - view on LGTM.com fixed alerts:
|
@@ -24,6 +24,7 @@ | |||
[disabled]="disabled" | |||
[labelHidden]="labelHidden" | |||
[autocomplete]="inferAutocomplete()" | |||
(setBlur)="onBlur($event)" |
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.
Angular linter complained here if I called this blur
or onblur
. So I changed the name to setBlur
The only UX I don't love here is if the user types in a password that's less then six characters long, and it matches the confirm password. An error won't display until they click somewhere else on the form. So they could possibly click the |
This pull request fixes 7 alerts when merging 8f8f118 into b15f97e - view on LGTM.com fixed alerts:
|
cy.findInputField('Confirm Password') | ||
.type(Cypress.env('VALID_PASSWORD')) | ||
.blur() | ||
.wait(100); | ||
}); |
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.
There is something odd timing wise, that I cannot duplicate in real life only in cypress. Where if you send the blur at the exact same time as you click the acknowledgement button it causes the validation not to fire and the button won't light up. That's why I added a wait in here. Not sure if there is a better way of handling the blur...
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.
Weird, we can keep an eye on it. Fortunately (and unfortunately) this isn't human-reproducible, so I'm good with the changes!
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.
👍
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 wanted to review this before the holidays because forms have been on my mind, particularly because of React Native support.
I think this PR has shown where we've outgrown our simplistic formData
structure and need meta data to support that complexity like https://formik.org/docs/overview#the-gist does:
- Validate entire form on submit
- Validate single/multiple fields (e.g. confirm password) on
blur
- Validate single/multiple fields on
change
- Accessing
touched.*
meta data - Accessing
errors.*
meta data
My only actual hesitation with this PR is that touched_*
properties become a public API that's accessible via formData
when customizing a service. But also knowing that form validation is tricky & we'll want to track touched
for most fields to perform more targeted validation.
touched_confirm_password, | ||
touched_password, |
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 had a feeling we'd come across this need sooner than later. Libraries like Formik (https://formik.org/docs/overview#the-gist) track a touched
object to maintain this state.
The dilemma I see here is that formData
now introduces 2 extra values that weren't present before.
This likely isn't a problem because our signUp
service has an allow-list of which values to send, but it seems like a smell to have a values for non-existent fields to track state, doesn't it?
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 that would make sense. Perhaps, we could add this in a future release? Seems like a big task
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 agree that having touched
context will be a desirable API on the long run, considering we'll look to document this for custom validators later on.
I personally think we should handle this from this PR to keep the API layers consistent. We can scope this to just the passwords -- I'll be happy to help too! (edit: I misread the code 😓 )
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 if I create a new formControls
context, that will have all the touched.*
values, at least for right now just for password
and confirm_password
. We can build on this to add in more form validation for the future, and it will remove the values out of formValues
into their own separate object. I'll push that up, so I can get your feedback.
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.
Pushed in 032b48b @ericclemmons @wlee221 . Is this what you had in mind?
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.
Awesome! One last nit -- what do you think about renaming formControls
to just touched
for now, and let the keys be ${name}
instead of touched_${name}
? Then when we need other formControls
, we can expose them as separate facade. I think this separation of form facades will improve DX than having a general formControls
, on the long run. What do you think @ericclemmons @ErikCH?
This will need some modification to runValidators
shape though... 😓 but I think now is a good time to make changes, before we document them!
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.
packages/react/src/components/Authenticator/SignUp/FormFields.tsx
Outdated
Show resolved
Hide resolved
…ssword too for all frameworks
This pull request introduces 1 alert and fixes 7 when merging 25c7dd6 into 2a486da - view on LGTM.com new alerts:
fixed alerts:
|
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 the update, this is a big change! Sorry my review was late. Got few comments around tracking blurred inptus.
cy.findInputField('Confirm Password') | ||
.type(Cypress.env('VALID_PASSWORD')) | ||
.blur() | ||
.wait(100); | ||
}); |
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.
Weird, we can keep an eye on it. Fortunately (and unfortunately) this isn't human-reproducible, so I'm good with the changes!
touched_confirm_password, | ||
touched_password, |
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 agree that having touched
context will be a desirable API on the long run, considering we'll look to document this for custom validators later on.
I personally think we should handle this from this PR to keep the API layers consistent. We can scope this to just the passwords -- I'll be happy to help too! (edit: I misread the code 😓 )
This pull request introduces 1 alert and fixes 7 when merging 032b48b into bb8906d - view on LGTM.com new alerts:
fixed alerts:
|
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.
Apologies my reviews are getting late. Had one last nit about formControls
🙏
touched_confirm_password, | ||
touched_password, |
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.
Awesome! One last nit -- what do you think about renaming formControls
to just touched
for now, and let the keys be ${name}
instead of touched_${name}
? Then when we need other formControls
, we can expose them as separate facade. I think this separation of form facades will improve DX than having a general formControls
, on the long run. What do you think @ericclemmons @ErikCH?
This will need some modification to runValidators
shape though... 😓 but I think now is a good time to make changes, before we document them!
This pull request introduces 1 alert and fixes 7 when merging 86533e8 into a72d999 - view on LGTM.com new alerts:
fixed alerts:
|
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.
LGTM, thanks @ErikCH!!
Issue #, if available:
#767
Description of changes:
Improved UX for confirm. Now it shows the error on blur, or when the value is over 6 characters
Validation occurs on blur (Less then six characters)
sign-up-error-on-blur.mp4
Validation occurs after six or more characters are type
sign-up-error-character-limit.mp4
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.