-
Notifications
You must be signed in to change notification settings - Fork 291
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
chore(ui-react-native): Add RN Authenticator fields validations #4107
Conversation
🦋 Changeset detectedLatest commit: 9cf3b87 The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 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 |
(Chatted offline, not a blocker) Question about setting context for assistive tech: How are we associating the field error messages with the input? Do we need to pass it as an accessibilityHint on the TextInput? Not sure if that's the correct approach; I think that's what they're doing here https://formidable.com/open-source/react-native-ama/components/TextInput/#haserror I also see this issue is still marked open on the RN repo :( |
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.
Looking good, excited to see this completed. Let me know your thoughts on the feedback
} | ||
|
||
export interface UseFieldValues<FieldType extends TypedField> { | ||
fields: FieldType[]; // return either radio or text | ||
fieldValidationErrors?: ValidationError; |
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 do you think of extending the return of fieldValidationErrors
with undefined
instead of declaring with the optional operator?
setFieldValidationErrors({ | ||
...fieldValidationErrors, | ||
[name]: runFieldValidation(field, values[name], validationErrors), | ||
}); |
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.
Rather than spreading fieldValidationErrors
here, what are your thoughts on passing an updater
callback as the parameter of setFieldValidationErrors
? Could be applied to all other state setting functions in this file
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.
Will address as follow-up since touches other parts not related to validation.
return { | ||
fields: fieldsWithHandlers, | ||
disableFormSubmit, | ||
fieldValidationErrors: { ...fieldValidationErrors, ...validationErrors }, |
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.
Definitely may be missing something here, but curious if validationErrors
still needs to be merged with fieldValidationErrors
since (if I am reading correctly} runValidations
has already concatenated the values contained in validationErrors
here?
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 covers the case where there is no blur or change event but there are state machine errors. We don't want to lose 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.
Maybe we should move the logic related to the machine errors out of runValidations
and create a util to be used here so we can have one source of truth in how state machine validations are merged with the local state validations?
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 was hesitant to make extra changes to this bc we're removing it with the upcoming auth work, what do you think, is it a blocker?
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.
My concern is mostly just that if for some reason the merging related code needs to get updated, it might be difficult to understand what's happening here without prior context. That being said if anything does come up it'll most likely be addressed by you or i so okay with it as is
packages/react-native/src/Authenticator/hooks/useFieldValues/utils.ts
Outdated
Show resolved
Hide resolved
packages/react-native/src/Authenticator/hooks/useFieldValues/utils.ts
Outdated
Show resolved
Hide resolved
packages/react-native/src/Authenticator/hooks/useFieldValues/utils.ts
Outdated
Show resolved
Hide resolved
expect(isValidEmail('TEST@EXAMPLE.COM')).toBe(true); | ||
}); | ||
|
||
it('should return false for an invalid email address', () => { |
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.
Nittish: Rather than running multiple tests that assert the condition within a single block the jest
idiomatic it.each
can be used for descriptive failures as each test runs independently, as well as improved readability of log output:
it.each([
{ desc: 'no domain name', email: 'test@' },
{ desc: 'an invalid domain', email: 'test@.' },
// ...other test scenarios
])('should return false for an email address with %s', ({ email }) => {
expect(email).toBe(false);
});
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 think the test is simple enough that it doesn't need "descriptive failures", it reads easier for me than it.each
but ultimately don't feel super strong about it, could have a follow up to refactor other tests where it.each
could be used. One observation I have is that currently this test runs in 1ms with all assertions, having a separate test for each assertion means each run in 1ms (I tested this). While it is negligible, I think we should pay attention to run times as well, as it can add up if this (it.each
) is the pattern we want to adopt going forward.
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.
We already use it.each
throughout the codebase. Adding 1 ms per test is fine if we are able to locate failing test case without having to comment out each test individually to find the failure (hypothetical situation). That being said this was a nit, so feel free to ignore 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.
I'll add an asana task! The failing test case points to the line of code so should be easy to locate but makes sense to be more verbose, there are other tests in the ui utils that don't follow it.each pattern, and could be updated 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.
Not sure what's going on with CI here but approved 🚢
Description of changes
This change adds validations for email and required fields for RN Authenticator only.
react-native
package.Issue #, if available
#3458
Description of how you validated changes
Ran tests locally, e2e run in CI
Simulator.Screen.Recording.-.iPhone.13.-.2023-06-16.at.17.47.27.mp4
Checklist
yarn test
passes and tests are updated/addedsideEffects
field updatedBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.