Skip to content
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.

Sign up for GitHub

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: correct minor typos in README #1760

Merged
merged 1 commit into from
Aug 28, 2022
Merged

fix: correct minor typos in README #1760

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -222,7 +222,7 @@ const reversedString = string()
Transforms form a "pipeline", where the value of a previous transform is piped into the next one.
If the end value is `undefined` yup will apply the schema default if it's configured.

> Watch out! values are not guaranteed to be valid types in tranform functions. Previous transforms
> Watch out! values are not guaranteed to be valid types in transform functions. Previous transforms
> may have failed. For example a number transform may be receive the input value, `NaN`, or a number.

### Validation: Tests
Expand Down Expand Up @@ -263,7 +263,7 @@ In the simplest case a test function returns `true` or `false` depending on the
passed. In the case of a failing test, yup will throw
a [`ValidationError`](#validationerrorerrors-string--arraystring-value-any-path-string) with your (or the default)
message for that test. ValidationErrors also contain a bunch of other metadata about the test,
including it's name, what arguements (if any) it was called with, and the path to the failing field
including it's name, what arguments (if any) it was called with, and the path to the failing field
in the case of a nested validation.

Error messages can also be constructed on the fly to customize how the schema fails.
Expand Down Expand Up @@ -1327,7 +1327,7 @@ await schema.isValid(''); // => true

Validates the value as an email address using the same regex as defined by the HTML spec.

WATCH OUT: Validating email adresses is nearly impossible with just code. Different
WATCH OUT: Validating email addresses is nearly impossible with just code. Different
clients and servers accept different things and many diverge from the various specs defining
"valid" emails. The ONLY real way to validate an email address is to send a verification email
to it and check that the user got it. With that in mind, yup picks a relatively simple regex
Expand Down Expand Up @@ -1590,7 +1590,7 @@ const schema = object({
schema.default(); // -> { name: '' }
```

This may be a bit suprising, but is usually helpful since it allows large, nested
This may be a bit surprising, but is usually helpful since it allows large, nested
schema to create default values that fill out the whole shape and not just the root object. There is
one gotcha! though. For nested object schema that are optional but include non optional fields
may fail in unexpected ways:
Expand Down