Afrikaans
Akan
Albanian
Amharic
Arabic
Armenian
Azerbaijani
Basque
Belarusian
Bemba
Bengali
Bihari
Bosnian
Breton
Bulgarian
Cambodian
Catalan
Cebuano
Cherokee
Chichewa
Chinese (Simplified)
Chinese (Traditional)
Corsican
Croatian
Czech
Danish
Dutch
English
Esperanto
Estonian
Ewe
Faroese
Filipino
Finnish
Frisian
Ga
Galician
Georgian
German
Greek
Guarani
Gujarati
Haitian Creole
Hausa
Hawaiian
Hebrew
Hindi
Hmong
Hungarian
Icelandic
Igbo
Indonesian
Interlingua
Irish
Italian
Japanese
Javanese
Kannada
Kazakh
Kinyarwanda
Kirundi
Kongo
Korean
Krio (Sierra Leone)
Kurdish
Kurdish (Soranรฎ)
Kyrgyz
Laothian
Latin
Latvian
Lingala
Lithuanian
Lozi
Luganda
Luo
Luxembourgish
Macedonian
Malagasy
Malay
Malayalam
Maltese
Maori
Marathi
Mauritian Creole
Moldavian
Mongolian
Myanmar (Burmese)
Montenegrin
Nepali
Nigerian Pidgin
Northern Sotho
Norwegian
Norwegian (Nynorsk)
Occitan
Oriya
Oromo
Pashto
Persian
Polish
Portuguese (Brazil)
Portuguese (Portugal)
Punjabi
Quechua
Romanian
Romansh
Runyakitara
Russian
Samoan
Scots Gaelic
Serbian
Serbo-Croatian
Sesotho
Setswana
Seychellois Creole
Shona
Sindhi
Sinhalese
Slovak
Slovenian
Somali
Spanish
Spanish (Latin American)
Sundanese
Swahili
Swedish
Tajik
Tamil
Tatar
Telugu
Thai
Tigrinya
Tonga
Tshiluba
Tumbuka
Turkish
Turkmen
Twi
Uighur
Ukrainian
Urdu
Uzbek
Vietnamese
Welsh
Wolof
Xhosa
Yiddish
Yoruba
Zulu
The next optimisation we'll work on is outputting multiple errors.
So far we've been outputting a single error rather than all of them.
This is so that we don't overwhelm the user with errors.
It would clutter the form visually.
However, in some cases you may want to output multiple errors for a specific input.
An example of this would be the password field.
I'm sure you've encountered a fair number of password fields.
They vary with their own rules.
Some examples would be requiring a minimum character length, using various characters or using numbers.
This is so that the user has a strong password.
It would be annoying to type out a password only to learn that it's missing something.
It would be preferential to render every error.
This will allow the user to adjust their password based on our rules.
Keep in mind that this is just my opinion.
There are different ways to tackle user experience.
It depends on the app you're building.
Regardless, I think this would be a good example of how to output multiple errors at once.
Search for the password field if you haven't already.
We're going to focus on the first field because the second field will match the first one.
It's not required to repeat the rules.
If the first input isn't valid, then neither is the second one.
The validate implements a fast exit strategy.
It's a strategy that will end the validation process.
If a single rule is broken.
If there are additional rules, they won't be checked.
This results in fewer resources and faster feedback.
This is why you'll only see one error at a time for an input.
We'll want to override this strategy.
If we want to output multiple errors on the field component, we're going to bind a property called
Bails.
We'll set it to false.
The Bales property will tell the field component not to use the fast exit strategy.
This means every rule will be checked, even if a previous rule was broken.
It's important to bind the Bales property because we want the component to interpret the value as a
false boolean value.
The next step is to loop through the errors.
Here's where a new problem arises.
Currently, we're using the error message component to output the errors.
However, it it'll only output one error at a time, even if the bales property is added to the component.
We're going to need to customize the behavior of the field component if we want to output multiple errors.
The field component has a slot we can take advantage of.
It's the only way we'll be able to output multiple error messages.
We're going to create an opening and closing field tag.
Since we're going to add some content, we need to output the input tag.
Validate will not do it for us.
Inside will pass in an input tag.
Well cut and paste the placeholder class and type attributes from the field component to the input tag.
Next we need to tell validate which input should be validated inside the slot content.
We're going to add the V slot directive to de structure the field property.
The field property is an object with the features for adding validation to an input.
We must add this property if we want to validate the input.
Otherwise, the validate will not be able to perform validation on the password field.
We can bind the property by adding the V bind directive to the input element.
We'll set it to field.
Next, we'll work on the error below the input.
We're going to add a div tag with the class text read 600.
We're using a div tag because we'll be outputting multiple errors.
Each error should be placed on a separate line.
The div tag will assure us of that from the v slot directive.
We're going to structure an array called errors.
The ER's array will contain a list of errors triggered by the input.
It's important to understand that the array will only be available if we set the bails property to false.
Otherwise, we'll always get one error.
We can loop through this array to output the errors on the div tag.
We'll add the v four directive.
The expression will be the following error in errors.
Inside the tags will output the error with an expression.
One less thing.
We'll need to add a key.
We'll bind the key attribute to the error alias in the loop.
This attribute isn't necessary, but view recommends we set it anyway.
We're almost finished.
The last step is to update the rules for the password.
At the moment we don't have a pair of rules that will appear along each other.
Scroll to the schema in the password field.
Set the minimum rule to nine.
Next set the excluded rule to password.
Allowing users to set their password to password is not considered to be a safe practice.
We should prevent users from using specific passwords during registration.
We're finished.
Save your changes and refresh the page.
I'm going to type password into the password field.
This input will cause the minimum and excluded rules to break.
The messages are the same because Validate uses the same message for every rule.
As long as you see multiple error messages, then you're good to go.
We'll continue optimizing the form in the next lecture.
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.