DEV Community: Alessio Carnevale

One Time Password component — an optical illusion?

Alessio Carnevale — Wed, 31 Aug 2022 14:31:02 +0000

Recently I have been building the login/register section of a web site where, at some point, I had to implement an OTP component to confirm the account creation: a component similar to the one in the screenshot above.

The first thing I thought when I saw the UI design was: “Ok, I need to create an array of <input/> elements and then add one or two hundreds of JS lines to handle the internal state, allow the user to enter/edit the code and to handle values pasted from the clip-board.

But then this question came to me mind: why?

Why do we have to implement such a design and more importantly: what problem are we trying to solve here?

Why do we need to have 6 input boxes and write all the logic to make them behave as if they were just a single input box?

Functionally speaking all we need to do is to allow the user to type in a 6 character string, yet most (if not all) the implementations of this component I saw on NPM are all basically following the same pattern: an array of input boxes and a lot of JS to make them work together seamlessly.

It feels wrong, there’s something I am not getting.

After spending some time with these questions in my head I came up with the following explanation: it is an optical illusion!

The origin of that design pattern probably dates back to the times where forms were printed on paper and people had to fill them manually, with a pen in their hand:

Having basically no control over the form filling process (we didn’t have client-side validation at that time) we came up with graphical solutions that would help the user to provide the data in a way that was as clear and correct as possible, i.e. in the screenshot above we have:

boxes to separate each character
pre-formatted date fields to clarify the date format

In the example above it is clear that “DATE OF BIRTH” has been broken down to 8 boxes to suggest the user that we need the date to be in the dd/mm/yyyy format rather than dd/mm/yy.

It is just a graphical treatment meant to help the user to fill the form in correctly.

These days we have electronic forms and those things give us full control over the filling process. We no longer need to split the information into its atomic parts to help the user to provide the correct data… and even if we decide to do so we can do it just at the graphical level.

The OTP component is (or should) be just that. From a graphical perspective it looks like a bunch of input-boxes but from a technical perspective it should be implemented as just one.

Building it as an array of inputs doesn’t solve any issue: on the contrary it requires a lot of effort to make it work and to maintain.

It is my candidate to the “Worst spent 200 lines of JS” award of the year!

To get confirmation that the OTP can be a simple text box I looked around and saw that these two big guys have implemented it exactly as a simple input element:

Let’s implement it anyway

So, in case we desperately need to implement a design like the one we saw at the beginning of this article, we can try adding some CSS and a few lines of Js.

Quick interaction example: https://youtu.be/iHdUOPLdRCM

A live demo is available in here

In essence, we need to use a monospaced font in our component as this way each character has the same width. This allows us to create and position some <span/>in the background to give the illusion of multiple input-boxes.

The code is fairly simple and should be easily customisable by anyone familiar with CSS and JS.

Final words

I had to write this down and share it with someone: is the OTP an optical illusion or am I hallucinating 🤔 ???

Your feedback would be highly appreciated!

Form validation/submission in vanilla React (part 2)

Alessio Carnevale — Sun, 28 Aug 2022 16:27:00 +0000

A not so trivial example

In the first part of this article I proposed implementing form validation/submission in vanilla React (no 3rd party libraries) using HTML5 and Constraint API.

The code example provided was intentionally simple to make the point that, if you build the feature on top of the native implementation, then you:

only need to write a fraction of code to handle forms
don’t need to learn how to use a new library
get a lighter JS bundle
reduce the number of dependencies
you don’t need to write tests for the validation fn, it’s already been tested!

This time I would like to add a less trivial component to our form: the password field.

The end product will look like this:

and the interactive demo is available here.

The password field in our form is responsible for validating the user input, testing it against the following 5 validation rules:

mandatory
at least one Uppercase
at least one digit
at least 8 characters
at least one special character

It also comes with the show/hide password button to toggle the password visibility.

The password component is built on top of the TextInput component we already implemented in part one. The only thing I added was the RhsComponent prop to inject the show/hide button:

The PlainTextToggle is just a button that toggles isPlainText state var between true and false. This in turn switches the input type between “text“ and “password”. I am not going to discuss this implementation further has it’s not in the scope of this article.

All the validation magic comes courtesy of the pattern prop!

Validating the password

As we know HTML5 allows for custom validation through the use of the pattern property. Pattern needs to be a valid RegEx… or the combination of multiple RegExes.

I am no expert when it comes to writing regular expressions so I googled around and found the following four (utils/validationRules.ts):

The first four lines in the above screenshot implement 4 of our requirements. The PASSWORD_VALID_REGEX further down is the combination (in logical AND) of the those four RegExes and that is what we are going to set in the password pattern property.

Please note that the password component is just this:

and, as we said, it’s pattern attribute is PASSWORD_VALID_REGEX i.e. the string that combines the 4 RegExes.

The fifth validation rule, required, is enforced by the “required” HTML attribute as we already saw when we implemented the name and email fields.

This code alone already implements all of our requirements!

Let me repeat this again: to implement all of the 5 validation rules we just need to provide one string and one attribute!

This is all this component needs to do: to get the user input and validate it against the pattern that comes out of the composition of 4 simple regular expressions. No more, no less than what the Tel field does in our form.

If it wasn’t for the show/hide toggle component then the password component code would have looked like this:

Check list

To improve the UX and provide visual feedback of the validation process we are now going to add the CheckList component:

It gets the password the user types in and runs it through the four RegExes to check which one is satisfied.

We start defining an array (rules) that gets mapped to an array of tags. If the pattern is matched then we add the “passed” className to tweak the style.

Composing them

Next step is to compose the PasswordInput and the CheckList components. We do this in the PasswordWithChecklist:

It simply funnels the password value it gets from PasswordInput into CheckList.

In the end

Our App.tsx now looks like:

Just one line taller than the one we have in part-one :)

Happy coding!

Form validation/submission in vanilla React (no libraries)

Alessio Carnevale — Tue, 23 Aug 2022 16:00:18 +0000

Form validation/submission in vanilla React (no libraries)

You don’t need a fancy library when you have HTML5 and Constraint API.

Link to part-two: a not so trivial example

The official React documentation suggests 3 possible ways to handle form submission/validation:

Controlled components
Uncontrolled components
Fully-fledged solutions (3rd party libs)

But none of these 3 methods are particularly appealing to me.

Controlled components: I personally don’t like controlled components as it involves manual state management that, most of the times, leads to unneeded and inefficient re-renderings.

Uncontrolled components: React docs suggests implementing uncontrolled components using a ref to get form values from the DOM but then doesn’t provide much info on what the best practises are to extract the data and validate it.

Either way, we are left with the non trivial task of implementing the logic to validate and collect the form data.

These days there are plenty of 3rd party libraries that do exactly that... but do we really need one?

The goal

Let’s build a simple form like this one:

Interactive demo available here.

We want to build a form implementing the following requirements:

Name and Email are mandatory
Email should represent a valid email address
Address is optional, no constraints
Tel is optional but if entered it should represent a formally correct UK phone number

On submit the form gets validated and should show validation errors like this:

In case of validation errors the focus should be moved to the first invalid field.

HTML5 and Constraint API

(Source MDN): HTML5 already has the ability to validate most user data without relying on JavaScript. This is done by using validation attributes on form elements.

required: Specifies whether a form field needs to be filled in before the form can be submitted.
minlength and maxlength: Specifies the minimum and maximum length of textual data (strings).
min and max: Specifies the minimum and maximum values of numerical input types.
type: Specifies whether the data needs to be a number, an email address, or some other specific preset type.
pattern: Specifies a regular expression that defines a pattern the entered data needs to follow.

If the data entered in a form field follows all of the rules specified by the above attributes, it is considered valid. If not, it is considered invalid.

Most browsers support the Constraint Validation API, which consists of a set of methods and properties that enable checking values that users have entered into form controls, before submitting the values to the server.

With these tools at our disposal we can build custom components for easy and efficient form management.

The solution

The building blocks of our solution are the following two custom components:

<Form />
<TextInput />

`<Form />`

The key attribute here is noValidate.

The novalidate attribute turns off the browser's automatic validation error messages. Without that our form would look like this:

All the magic happens in the handleSubmit callback:

we stop the form submission with e.preventDefault()
we make a note of the form validity state with isValid
we add the “submitted” className to improve the UX (more on this in a moment)
we move the focus to the first invalid field, if any
we collect the form data and call the onSubmit callback, if valid

The last one is another key point of this solution: collecting the form data using the FormData object. There is no need to manually go through the form elements and extract their values.

“The FormData interface provides a way to easily construct a set of key/value pairs representing form fields and their values” —( source: MDN)

`<TextInput />`

The TextInput component is responsible for rendering the input field, the label and the possible validation error.

You can see the code here, but essentially this component sets an internal state variable with the validation error string coming from the constraint API and resets it on blur if the error has been fixed:

Implementation

The code to implement the form in the example looks like this:

Things to notice:

We set the required attribute on Name and Email
type=”email” makes sure Constraint API checks the input is a valid email address
Address as no validation rules
Tel is not required but we set the pattern attribute to check the input against the regex (setting type=tel doesn’t enforce any built in validation)

Whenever we need to add another field to the form we just add a new TextInput and we set the relevant attributes to it.

No need to update schemas or add yet another useState to track the value of the new field, lets just offload the heavy lifting to the built-in API!

Improving the UX

The final touch to improve the UX is to show validation errors only after the form gets submitted.

Using just the :invalid pseudo class in our CSS to style incorrect fields would cause red highlighted input boxes and error messages to appear as soon as the page loads… and we don’t want to scream in the face of a user that his/her input is incorrect before they even have the chance to type a character in!

For this reason we add the .submitted className to the form and style the TextInput with this:

i18n

One great thing to keep in mind is that the constraint API validation messages are localised by default — i.e. they come in the locale the user OS is set to!

If you are happy with the default messages then there is nothing else you need to worry about: your English, Spanish, Italian or Chinese users will get the messages in their own language.

The TextInput component provided in the example allows also for basic validation message customisation via the errorText attribute:

This is just an example to show how one could customise those messages.

Finally

Once the form is formally correct we can actually submit the from in the onSubmit callback.

We receive a FormData object which can then be easily sent using the fetch() or XMLHttpRequest.send() method. It uses the same format a form would use if the encoding type were set to "multipart/form-data" , or we can transform it in more familiar key/value object:

to produce the following:

Final words

There is beauty in simplicity and form validation/submission doesn’t get much simpler than this IMHO 🙂

Any comment / feedback is much appreciated!

Link to part-two: a not so trivial example