React Forms — Form Input Types

This time we will be taking our form to the next level and taking a look at most of the input types available to us.

Link to last time,

https://medium.com/@natey37/react-forms-frontend-validations-e7e094da4eba

Using our form from last time, we can see that we have used a type=’text’ and a type=’date’. Now we are going to see the rest of them.

First, we will take a look at check boxes.

We will create three checkboxes with three different options. Usually we use checkboxes when we want to give the user the choice of multiple different options. In our case we want to know how great this person is, so our options will be ‘talented’, ‘smart’, and ‘funny’. We need to add a state for our checkbox inputs, so we will add a variable ‘checked’ to our state and set it equal to an object that contains our checkbox values. In this case all set to false since we want them to start off unchecked.

Now, let’s make a function that will handle our checkbox.

When our checkbox is clicked on, the onClick function will run the handleChecked function. This sets the corresponding checkbox value in checked to true or false.

We can see a few things are different here. We have changed the type to ‘checkbox’, and now we have this attribute checked. This takes a true/false value that determines if it’s checked or not. We are checking our form.checked and then checking the boolean value of the the appropriate checkbox.

Next we will take a look at the color input.

The type=’color’ field is designed for capturing RGB colors in hexadecimal notation, such as #aabbcc. Most browsers will provide a color picker for you, but in the case that it is not supported your user will need to enter a valid hex number on their own. Keep that in mind when using it.

Let’s make it fun and change the background color of our form to whatever they choose as their favorite color.

Here we are checking to see if our form.color has a value. If it doesn’t it just uses our default background color. If a color has been chosen, then it sets the background color to the chosen color.

Next is the datetime-local type.

The date and datetime-local are needed quite frequently, but there are some things to consider. These field types provide a standardized, accessible and consistent user interface to capture the date and times from the user. The value gets stored as a year-month-day value such as 2020–07–29. This is great for developers, because they map well to the ISO 8601 date format. However, if our users browser does not support this type, then they are left to enter a date in this format which is not the obvious choice for most people. We then need to make sure it’s clear to the user on what the expected input needs to be.

There is an email type that has certain validations already built in but since we already created our own we will skip this for now.

Next is the file type:

The built in file input is unsightly so we will keep this hidden and just show our label, which because of the htmlFor association will trigger the file selection when clicked. When our user has selected a file and our form has a value for file, we will let the user know their image has been uploaded.

Next is the hidden type.

This input lets web developers include data they don’t want seen or modified by users when a form is submitted, and is often used for storing something like an associated database id. Be aware that is it not visible in the page content, but can be seen using the browser developer tools, so do not use this as a form of security.

Our input is hidden, so I added a button. When clicked it will show the hidden text from the input.

Next is the number input.

The min and max values represent our lower and upper bounds, and the step value represents what we will count by. In this case our options are odd numbers from 1–9.

Next is the password type.

The password input type masks your characters. It is sometimes useful for users to be able to see what they are typing, so I added a button to reveal the characters.

Next is radio buttons. You generally use these when you want your user to choose one option.

We need to make sure all of our radio inputs have the same name and change the value to whatever we want that option to equal.

Next is the range type.

We use this for entering a number when the exact value is not very important. We use the min and max to specify lower and upper bounds for the values (default is 1–100), and again there is a step option to change what you count by.

Next is the reset input.

It is recommended to not use this in case of user frustration from accidentally deleting their information they just entered. Although I see its practicality in some use cases. We will skip this for now, but it does exactly what says. It resets all input fields so they are the initial value.

Next is the search type.

We really don’t need a search bar on our form so we will skip this as well, but the search type is functionally equivalent to the text type. Except it allows users to style it differently and it comes with a close icon which resets your search field.

Next is the telephone number.

We add a pattern, which must be matched or alerts the user they must match the requested format.

Last but not least we will cover the url type.

The URL type has built in validations that accept only full, absolute URLS. There is no option to capture just a domain name or just a path.

That’s it for now. Next time we will hook a database up so we can start saving our users forms.