Forms are ubiquitous in web applications. Some apps such as Gmail use forms to collect data to sign up users and provide an email address, whereas some apps such as PayPal use forms to fulfill online transactions to facilitate shopping experience. Some web forms are used to apply for a new car loan whereas some forms are used to order pizza for dinner. It is, therefore, important that the data collected from forms is cleansed, formatted correctly and devoid of any malicious code. This is called form validation.
We need form validation anytime we are accepting a user input. We must ensure that the data entered is in correct format, lies within a valid range of data (such as for date fields) and does not contain malicious code that could lead to SQL injections. Malformed or missing data can also causes erroneous results from API.
Form validation can happen on -
- Client side and
- Server side.
In other cases, you may have noticed that when you fill out a form and enter details such as a credit card, it may show a loading screen and then show an error "This credit card is invalid". Here, the form made a call to its server side code, and returned a validation error after performing additional credit card checks. This validation case where a server-side call is made is called server side validation.
Form validation is needed anytime you accept data from a user. This may include -
- Validating the format of fields such as email address, phone number, zip code, name, password.
- Validating mandatory fields
- Checking the type of data such as string vs number for fields such as social security number.
- Ensuring value entered is a valid value such as country, date, etc.
On client side, validation can be done in two ways -
- Using HTML5 functionality
HTML5 provides a bunch of attributes to help validate data. Here are some common validation cases:
- Making fields required using
- Constraining the length of data:
maxlength: for text data
maxfor max value of num type
- Restricting the type of data using
<input type="email" name="multiple>
- Specifying data pattern using
- specifies a regex pattern that entered form data needs to match
When the input value matches the above HTML5 validation, it gets assigned a psuedo-class
:invalid if it doesn't.
Let's try an example -
<form> <label for="firstname"> First Name: </label> <input type="text" name="firstname" id="firstname" required maxlength="45"> <label for="lastname"> Last Name: </label> <input type="text" name="lastname" id="lastname" required maxlength="45"> <button>Submit</button> </form>
Here we have two required fields - First Name and Last Name. Try this example in JSFidle. If you skip either of these fields and press submit, "Please fill out this field". This is validation using in-built HTML5.
When implementing form validation, there are a few things to consider -
- What is defined as "valid" data?
- This helps you answer questions such as the format, length, required fields and type of data.
- What happens when invalid data is entered?
- This will help you define the user experience of the validation - whether to show an error message inline or top of the form, how detailed should the error message be, should the form be sumitted anyways? Should there be analytics to track invalid format of data?
- HTML5 Constraint validation API
pattern HTML attributes can help perform basic validation, but if you want more complex validation or provide detailed error messaging, you can use Constraint Validation API. Some methods provided by this API are -
The following properties are useful -
In this example, we will validate using HTML5 inbuilt methods such as
length in conjunction with Constraint Validation API to provide detailed error messages.
Client side validation is not the only validation check you should do. You must also validate the data received from your client on server side code to ensure that the data matches what you expect it to be. This can be used to perform business logic verifications that should not live on client side.
- Always have server side validation since malicious actors can bypass client side validation.
- Provide detailed error message in-context with the field that produced an error.
- Provide an example of what the data should look like in case of an error message, such as - "Email did not match format - email@example.com"
- Avoid using single error pages that involve redirection. This is bad user experience and forces the user to go back to previous page to fix the form and lose context.
- Always mark required fields.