Original subtitles

Up until now, we've been stuck with the same error message for every rule.

The reason we get the same message is because of how rules are defined in the validation file.

We're using the defined rule function to create our rules.

The second argument to the function is a pure function.

The pure function can return one of two values.

It can return true if the validation passes.

Or it can return a string.

If it returns a string, then the validation fails.

The string must be a message to tell the user why the validation failed.

It's important to understand this we aren't creating our own rules.

Instead, we're using rules from the validate rules package.

The functions we're importing don't return a string.

If a validation fails, they're returning a false boolean value.

The validate provides a way for overriding a message.

There are some limitations to what we can override.

Firstly, we can only overwrite messages from global rules.

Keep in mind we're allowed to define rules locally.

A local rules error message cannot be overridden.

The second thing to understand is that this will only work for functions that return a false boolean

value.

If the functions from the package returned in actual string, we wouldn't be able to override those

messages.

Luckily they do, so we'll be able to override them.

Let's explore how that's done.

We're going to create the custom messages in the validation file at the top.

We'll update the import statement for the configure function.

The configure function can be used to configure the default behavior of the validation library.

We'll be able to override the default messages from our global validators inside the install method.

We'll call the configure function.

This function has one argument, which is an object with the configuration options.

There's one option we'll want to add called generate message.

This option will be an arrow function where we'll have access to a parameter called context.

The generate message function will be called whenever a global validator function returns false.

This function will handle all global validators inside the function.

We must return a string that will represent the message we want to output to the document.

The context parameter is an object information about the field being validated.

We'll have access to the name, value and rule being broken by the fields.

We can use it to help us output different error messages based on the rule being broken inside the function.

We're going to write a message for every global rule we defined in the install method.

We'll start from the top and work our way down.

We'll declare a variable called messages.

It'll be set to an object.

We're going to add a property for every rule.

The name of the property will correspond to the name of the rule.

It's crucial we use the same name because it's how we'll be able to search for the rule when we need

to output it.

You'll see what that looks like in a moment.

The first rule is called required.

Its value will be the following.

The field context field is required.

From the context object, we can access the name of the field via the field property.

We're using a string template for inserting the name into the string.

We'll keep moving forward.

The next rule is called Min.

Its message will be the following The field context field is too short.

Then we have the max rule.

The message will be the following The field context field is too long.

Subsequently we have the alpha spaces rule.

The message will be the following The field context field may only contain alphabetic characters and

spaces.

Afterward we have the email rule.

The message will be the following The field context field must be a valid email.

Up next, we have the min value rule.

The message will be the following.

The field context field is too low.

Similarly, we have the max value rule.

The message will be the following The field context field is too high.

There are two more rules left.

We're going to approach these two slightly differently.

The excluded rule will check if the input does not match the list of values.

However, the excluded rule can be used for other scenarios.

We have to choose between a generic or specific message.

However, there is a solution where we can have both.

We're going to add the excluded rule to the object.

The message will be the following.

You are not allowed to use this value for the field context field.

This message works great, but we want to give a more specific message in the registration form.

We want to tell the user that they're not allowed to sign up for a certain location.

One way we can add messages for specific inputs is by creating a rule specifically for the fields.

Let me show you what I mean.

We're going to make a copy of the excluded rule.

The name will be country excluded.

We have two rules that do the exact same thing.

However, they have different names.

This allows us to create a message for generic scenarios and another for specific inputs.

Back in the messages object, we can add this rule to the list.

We'll set the message to the following.

Due to restrictions, we do not accept users from this location.

Great.

We have a special message for the country fields.

We're going to update the name of the confirmed rule to passwords mismatch.

We are going to create a copy because we'll only be using this rule once.

We don't need to create a generic message inside the messages object.

We'll add the passwords mismatch rule.

The message will be the following The passwords don't match.

There is one last rule will add.

The default message for the terms of service doesn't sit well with me.

The terms of service are using the required rule.

We want to tell the user directly they must agree to the terms of service.

We'll make a copy of the required rule because we'll need one copy for generic scenarios and another

for the terms of service.

The name of the copy will be to iOS and the messages object will add the following message For this

new rule you must accept the terms of service.

We have two rules that do the same thing.

They require the user to input a value.

The difference being is the message the required rule can be used for regular inputs, while the toss

rule is specifically for the terms of service checkbox.

We're finished writing the rules.

The next thing we'll do is tell validate which message to use.

We'll declare a variable called message.

It's now you will be a ternary operator in the condition.

We'll check if the messages context dot rule name exists.

The rule name property refers to the name of the rule that was broken.

We want to check if a message for this rule exists.

If it does, we'll set the message variable to it.

Otherwise we'll have a generic message which will be the following.

The field context field is invalid.

Afterward, we'll return the variable.

We're not going to add any more custom error messages.

There's one last thing we need to do.

We'll need to update our form to use the custom rules we created in the object.

Switch over to the authentication component.

We'll need to update the schema data property.

For the password confirm field will change the rule confirmed to passwords mismatch.

Next the country field will have its excluded rule changed to the country excluded rule.

Lastly, the toss field will use the toss rule instead of the required rule.

Let's give things a test.

Open the app in the browser.

First we'll test the country selection.

I'll select Antarctica.

The error will tell us that we're not allowed to register from this location.

This is a much better message than before.

Next, let's test the terms of service checkbox.

If we were to one, check the box after checking it.

We'd see the custom error message, even though the name of the rule is different.

It'll still work because the configuration is the same as the required rule.

Lastly, let's test any of the other fields with the required rule.

We've successfully created error messages for the other fields.

One of the most important things I want you to be aware of is how we handle generic and non generic

messages.

We had copies of the same rules under different names.

This allowed us to maintain generic messages while also handling special cases.