Validating the Web: The Evolution of Form Validation

Hello everyone. I'm thrilled to be with you today to talk about validating the web, the evolution of form validation. Forms might not be the sexiest topic around, but they are where the money happens in our applications, so I'm excited to be here and show you a new approach to form validation. I want to say thanks to the React Team Summit for having me and also for this opportunity.

Before we begin on the topic of this talk, let's take a brief look at how the web evolves. So in the beginning, Sir Tim Berners-Lee and his team invented HTML and launched the first website, giving birth to the World Wide Web. A few years later, from the early nineties till the 2000s, at this point the web was mostly static, but with the introduction of the form tag in HTML2, it changed everything. It was our first real step towards interactivity. From then till 2015, this period transformed into the era of Web 2.0, bringing true interactive experiences through social applications and user-generated content.

For the first time, people were at the center of the web. From then till now, Web 2.0 matured and we began transitioning to Web 3.0, with a higher focus on decentralization, leveraged by blockchain technologies and a greater user ownership of data and digital assets. Taking a glimpse into the future, I think we can all agree that AI and AI integrations will be everywhere and they will fundamentally change the way we interact with the web. What's fascinating in the middle of all of this evolution is how the humble form tag has remained consistently important through all of these stages till the present day.

I'm Luiz Oliveira, I'm a staff engineer at XGeeks and you can find more about me on my site luizfilipppt.com. By the way, PT does not stand for personal trainer. I don't know why, but I get asked this a lot. It really stands for Portugal, the country where I'm from. This talk was actually inspired by Evitar, whose talk last year completely changed my perspective on form validation, something just clicked when I heard him speak. And I am here today to share some of those insights with you. Evitar is a great person and a great engineer working at Meta. And if you're interested in the React, I highly recommend to follow his work.

Let's be honest. Forms are where the money happens in our applications. They are how users input data, make purchases and interact with our systems. As you can see in the flow diagram appearing on the screen, form validation is far more complex than it first appears. We start with form submission, validate inputs, check if fields are required, validate on the server. By the way, if you're not validating on the server, feel free to leave this talk and come back later, because server validation is crucial for form validation.

Back to the content. So we show error messages, we wait for users to correct input, and this cycle can go on and on. We can repeat this multiple times. And all of these intricate flows create significant challenges, like complex structure requirements that are hard to maintain, ensuring validation consistency across different parts of our applications, managing both client and server-side validations, handling various validation scenarios and edge cases, providing meaningful error messages to our users, and feedback that guides them through the experience. And when forms fail, we literally lose money. Users abandon purchases, applications remain incomplete, and conversion rates plummet. This complexity is exactly why I think we need better approaches to validation.

Let's just take a look at the current validation landscape, and it can get quite overwhelming. If you look at this npm search result, it says there's over 1,000 packages related to form validation, and this is just the way that npm displays results. There's over 10,000 packages related to form validation. And this tells us two things. One is that form validation is a widespread challenge, the other one, there's no single solution that fits all the needs. There are different validation approaches out there, but probably the most used are schema validation packages and framework validation packages. The first are great for server-side validation and data structures, but they feel a little, I don't know, disconnected from the user experience, since users don't really type into a schema.

The second one, framework-specific, they are great, but they can sometimes feel overly opionated, and they always vendor lock you into some framework or into some pattern. What developers really need is something that's flexible, reusable, and maintainable that can handle complex scenarios without sacrificing developer experience or performance. Let's take a look at VEST. VEST was created by Avatar and takes a new and fresh approach to solving some of these challenges. It was inspired by unit testing frameworks and brings those familiar patterns to validation. It's easy to learn, especially if you have used it just before. It's framework agnostic, smart, powerful features, and performance optimizations out of the box. It's fully reusable across client and server environments, solving the classical duplicate validation problem.

And now I will play a short video that shows the striking similarity between Jest test code and VEST validation code. So we start with Jest, where we use terms like describe, groups, tests, and expect that checks results. Then moving to VEST, describe turns into VEST create, you will see it in the end of the video, and expect becomes enforce, which applies validation rules. VEST also takes an extra parameter in each validation, which is the field name to validate. And of course, the whole validation suit gets the form data to validate. This structure is very similar to Jest, just with a few new details, making the switch easy to understand. And this familiar approach means that we can get up to speed quickly, and our validation logic becomes clear and maintainable.

Just like tests, our validations now express exactly what we expect from data. Let's take a look at one of VEST's features, how cleanly it separates validation logic from your UI code. Let's take a look at this code example to understand why this matters. As we can see, we have distinct, clearly separated sections. We have our validation suit, where we import VEST course functions, create, test, and enforce. We define our validation logic in a completely UI agnostic way. And our password validation rule simply states password must be at least eight characters long.

Below that, in a separate component file, we manage form state with the react's use state. We run the validation against our current form data. We render our UI component with the form fields. And we display errors when the validation fails. So this separation gives us several major benefits. Our validation logic lives completely independently from UI concerns. You can reuse the same validation across different components or even different platforms. Changes to the UI won't affect your validation rules, and testing becomes dramatically simpler since the validation logic is fully isolated.

New team members can quickly get up to speed and understand validation requirements without having to dig through UI code. In complex applications, this separation becomes even more valuable as complexity grows. Now, let's take a look at one of my favorite VEST features, asynchronous validation. In real-world applications, we often need to validate against external data sources, like say, for example, a server. One classical example of this is checking if a username is available or if it's already taken. If we look at this example code, VEST makes async validation surprisingly straightforward. On the left, we have our validation code with two key features. We have the only, which is the only keyword function, which receives the current field and allows us to validate just a single field at a time, which is perfect for those on-blur validations.

Second, look at test.memo, which caches the result of the call to the server or any external data source and only reruns this validation when that value changes. In our foreign component below, we use suit.isPending. We pass it the field name so that we can easily get a loading state that lets us provide immediate user feedback while the async validation completes. VEST handles all the complexity of managing pending states, caching results, and assuring validations run in parallel when possible. Users get immediate feedback and the code stays clean and maintainable.

The UI example on the right shows what the user will experience. When they type a username, they see the validation happening in real time, including the check against the external data source. If the value is in VEST cache already, then the validation is instant. The video is in the loop, but you can notice that the first time that pith and ptr values are checked, a loader pops up while the check is happening. But the second time that these values appear on the input, the feedback is immediate.

Another powerful VEST feature is the ability to share the validation logic between your client and server code while maintaining the validation state across them. Let's take a look at yet another code example. We have our shared validation logic that's used in both environments. In this case, we have a simple username validation that checks if it's empty, and then the same validation suit is imported and used in both client and server codes. In our server, we receive foreign data from a post request. We run the validation suit against the data. We serialize the result of the entire validation state to JSON and send it to the client. Then, in our client code, we have a React component responsible for managing state. When we receive the server response, we use it to restore the validation state, and this allows us to pick up exactly where we left off on the server.

This pattern is incredibly useful for several different use cases. Client-server validation, where we validate critical data on both sides using the same rules. Persistency, we can save the validation state between user sessions or steps in multiple step forms. For debugging, since you have the full validation state when troubleshooting, debugging becomes a lot more easy. This approach solves one of the most frustrating problems in development and in foreign validation, which is keeping the validation logic consistent across the stack.

With VESC, we can write our validation code once and use it everywhere. Let's now take a look at yet another VESC feature. Warning states. Sometimes we need more than a simple pass-fail validation. VESC introduces a powerful concept called a warning state that gives us a middle ground between valid and invalid fields. Taking a look at this code example, in the validation suit above, we are using the warn keyword, the warn function. Inside our password test, and this simply says that we want this password to have a number, but it's not a hard requirement. We suggest adding the number to strengthen the password.

In the component below, we get both errors and warnings. We can join them together to display all the messages to the user. But if the form only has warnings, it can still be submitted. If it has errors, they block submission. And in the demo video, you see how this creates a much better user experience. Instead of blocking submissions for non-critical issues, we can guide users towards better practices without actually frustrating them. We can create progressive validation experiences. We can implement things like password strength indicators. We can suggest improvements while still allowing submission. We can also differentiate between must fix and should consider fixing. And the subtle distinction between errors and warnings creates a more nuanced, user-friendly experience. All of these things respect our users' time while still encouraging best practices.

Just think, how many times have you abandoned a form because of some overly strict validation? It probably has happened to you before, and warning states help to mitigate that problem. Another common challenge in form validation is handling related fields validation. That means that one field's validity depends on another one. A classical example, the one I bring here, is password confirmation fields.

So taking a look at the code example, we have our standard pass validations at top, require length check, and then the highlighted section shows a powerful pattern bypassed using skip when. We tell vest to skip the validation of the confirmation field until the user has actually start typing in it. Then we validate that the confirmation matches the password. And this pattern creates a more natural user experience. We don't want to show confirmation errors before the user has even started typing on the confirmation.

The form on the left shows what the user's with experience. They can fill out their username and password first, and only when they start typing into the confirmation field does vest begin to validate that relationship between the fields. But password confirmation is not the only example. There are several common use cases where this related field validation is important. State ranges, where an end date must be after a start date. Address validations where a zip code must match a city or a state. Quantity fields where a minimum order must be less than some maximum number. Multistep forms with dependencies between the steps.

So vest makes all these relationships easy to express and maintain while keeping our validation logic clear even as complexity grows. As we wrap up today, I want to leave you with a few key thoughts about form validation. Forms are truly our heaviest connection to the users. They are how users interact with our applications in the most direct and meaningful way. When we create forms, we're creating conversations between our applications and our users.

And let's be honest once more. Forms are the money makers of our applications. They are how users sign up, make purchases, submit information, and convert to become loyal users of our products and applications. So when form experiences are poor, we are losing money. Literally losing money. Users abandon our applications. They leave our products. That's why form validation deserves our love and attention. It's not just a technical requirement.

It's a critical part of the user experience that directly impacts the success of our applications. Trivest takes a fresh take on this challenge by bringing those familiar testing paradigms to validation. It makes our code, like I showed, more maintainable, our validation logic more isolated, therefore more reusable, and overall the user experiences get better. I encourage you to try Trivest in your next project. Either you're building a simple contact form or a multi-step complex form in some complex application, I truly believe that a fast approach can help you create better validations with less effort. Try it and come back to me and give me feedback.

So as I end this talk, I want to thank you all for joining me. I hope you have found some useful insights to take back to your own projects. One last thing, I will be attending the Live React Summit event in Amsterdam, so if you're going to be there, I would love to connect in person. Whether you want to dive deeper into React development or you just want to grab a drink and chat, please feel free to reach out. You have all the ways to reach to me in my site. Thanks again for your attention. I hope to see you in Amsterdam. Thank you.