Original subtitles

In this lecture, we're going to continue working with the name field, the goal is to add additional

rules.

First, I want to introduce alternative syntax for adding rules quickly will continue working on the

authentication component.

We learned that we could apply rules by adding the rules property on the field component for the name

input.

The format for adding a rule is to pass in the name of the rule as the value the names should correspond

to the name you assigned the rule in the first argument of the defined rule function, we have the option

of using objects for more complex rules.

We can use objects by binding the rules property.

This binding will allow us to pass on an object and replace the current value with an object, every

property in the object will represent a rule.

The queen name should be the name of the rule you'd like to add.

For this example, let's add the required rule back in.

Some rules allow you to configure how they get enforced, it varies from rule to rule.

If you'd like to set a rule, you can use the property's value to do so in the case of the required

rule.

It doesn't have additional options.

If a rule doesn't have additional options, we're required to set it to true.

If we're using the object syntax, this will result in the same thing as before.

This alternative syntax can be handy if you prefer object syntax instead of strings.

The benefit of using an object is it allows you to outsource the rules as a data property.

If you have too many rules, then converting it into an object may be beneficial for readability.

We won't be using the rules object on the field component.

We already have the validation schema properties set to an object for outsourcing our rules.

I prefer to use the schema because we can centralize our inputs rules in one object.

Let's work on adding some more rules.

Open the validation file.

We're going to add three rules called minimum, maximum and alpha spaces will update the import statement

to include these rules.

The minimum rule will check if the input is not less than a specific length of characters.

This rule is to prevent users from entering one character in an input and moving on.

The maximum rule will check if the input is not greater than a specific length of characters.

In some cases, you may have a database where there's a character limit that you can't exceed.

You don't want to allow users to insert large strings because that will take up unnecessary space.

It's always a good idea to set a maximum limit.

The Alpha Spaces rule will allow the input to contain alphabetic characters or spaces.

People don't typically have names with numbers or other characters will want to limit the character

set to alphabetic characters and spaces.

In the import statement, we were assigning the Alpha Spaces Rule and Alias.

This is because we have an S linch rule that does not allow underscore characters for important names.

We have to use camel casing.

The Alpha Spaces Object uses an underscore character to prevent s lint from throwing an error.

We're using an alias to convert it into camel casing, a minor inconvenience.

We're still going to use the underscore for its name when we register it.

After importing the rule objects, we're going to register them with the define rule function.

The next step is to use the rules, switch over to the authentication component file.

Scroll down to the schema object in the data function.

If we want to add additional rules, we can separate each rule with a pipe character lets and the three

rules we registered will start with the minimum rule, unlike the required rule.

The minimum rule has an option for setting the minimum character length.

To set the option, we need to add a colon after the rule followed by the value will set the minimum

character length to three.

Afterward, we'll add the maximum role, we'll set it to one hundred.

This rule will limit the field from having more than one hundred characters.

The last rule will add is alpha spaces.

There are no options for this rule.

We have a total of four rules.

Let's test if they work back on the browser, try inputting a single character into the input.

Will receive an error, telling us that the field is invalid.

It would be better if the year were more descriptive.

We'll look at customizing the error message in a future lecture.

I'm going to type some additional characters.

The error will go away.

I should be allowed to input spaces if I want.

If I were to input a number, then the Alpha Spaces rule will get broken.

It'll only allow us to input alphabetic characters or spaces.

This is great.

The rules are being enforced like we want them to.

There are two things I want to talk about before ending this lecture.

Firstly, we validate follows a fast exit strategy.

By default, it'll stop validating the input field upon encountering an error.

In a way, this makes sense.

There's no use in checking the rest of the rules if one rule has already been broken.

This results in better performance and even provides a better user experience because the user will

receive feedback faster.

There is a way to output multiple errors.

We'll look at an example in a future lecture.

Secondly, validation will not be performed on an empty field until the initial value has been changed.

You'll notice that we don't receive an error when the form first appears on the page.

Validate will not enforce the rules until the input has changed its value.

This behavior is beneficial to us.

We don't want to start displaying errors to users when they haven't even had the chance to fill it out.

Otherwise it would be annoying.

That wraps it up for this lecture will continue in the next one.