Replacing Form Libraries With Native Web APIs

Hi, everyone. So my name is Jamin. So today we're going to be talking about how you can replace form libraries with native web APIs. So most of us know about these web APIs, but we really don't know what they do. For some of us, this might be the first time we're mentioning all of this. So we're going to talk about this from the React perspective and also how we can throw a lot of things to the web browsers to handle them for us without having to do them.

So before we begin, a little bit of introduction about me. So I'm Trust Jamin and I work as a developer advocate at Upload Care. So Upload Care is a file uploading service where we render file uploading solutions to our customers. And you can find me on social media as Code Jagaban. So on all social media platforms and even on LinkedIn, you can find me as Code Jagaban. So as a React developer, if you've built React forms before, you know that building forms in React is very difficult because sometimes when you have to build a form, you need to use a lot of view states. You have to manage inputs. You have to manage errors. You have to manage states and all that stuff.

And so sometimes you end up with having up to 47 use states. And you might be smiling now. It's okay. My form works now, but still, it introduced a lot of performance issues. And so this led to the introduction of form libraries, such as React Hook Form and Formic and all that stuff. I personally use React Hook Form. It's my favorite library for form management. And while doing that, it also introduced a lot of dependencies and also complexity for anyone who has not used that before. So it kept me thinking that, what if we could build forms with just the web-native APIs? What if the browser is already handling this for us and we're just trying to do it extra? What if we could just try to build forms with web-native APIs first before taking the approach to using a library or something? So that is what we're going to talk about today.

And so the first thing we want to talk about is we have three things to cover. So we'll talk about the constraint validation API, which is an API that is available to all web browsers today. We'll talk about the way React 19 handle form actions, which gives us a very good way to introduce web APIs into that mix. And then we're going to talk about a CSS pseudo-class that has been available, but not all of us know about it, which is the user-valid and user-invalid pseudo-classes.

Combining all of this together, we can see how we can build a lot of very good forms without introducing any libraries into our project. So first, let's talk about the constraint validation API. The constraint validation API has been around for a while. And the way it works is that it gives the browser the ability to validate fields that are being typed into by users. So by this, it provides you with various things. So one example is pattern matching via regex.

Each time you have an input and you say input, the name is an email, the type is an email, and is required, you're automatically triggering the constraint validation API. And the browser will sort of try to validate that field to the best of his abilities. It also provides you with range checking as well. So min, max, step, that kind of stuff. And then the cool thing about it, you can also set your own custom validity messages. So if you validate an input and, okay, the email is not valid, you can set your own custom validity messages.

And so this also provides you with real-time validity state object that you can use. The best part is it runs on your browser engine, eliminating the need for extra effort in your applications. The validity object offers features like input.validity.valid to check if an input is valid. You can set custom validity messages using input.setcustomvalidity with your error messages.

React 19 introduced form actions, allowing React forms to be submitted similar to HTML forms. The action function accepts the function and automatically receives native form data. The use action state provides a pending state and error message, reducing the need for controlled inputs and renders in React applications. This simplifies form submission and minimizes the use of multiple use states in form handling.

The CSS pseudo-classes input.user.invalid and input.user.valid validate input fields using CSS without JavaScript. These pseudo-classes trigger validation when a user interacts with an input element. They help detect a dirty state after user interaction, confirming input validity without JavaScript. Combining these features, such as custom validity messages, form actions, and CSS pseudo-classes, enhances form validation and submission in web applications.

And with this introduction of use action states, we no longer need to have a lot of controlled inputs to submit a form. This means we will have fewer renders in our React application. Using React 19 form action helps avoid writing many use states when working with forms. The pseudo class input.user.invalid and input.user.valid can validate fields using CSS, triggered by user interaction, confirming input validity without JavaScript. The invalid state only fires after user interaction, helping detect a dirty state if needed.

In a practical demonstration of these features, a simple React form using use action states is shown. Adding the required attribute triggers custom validation API, displaying validation errors for incomplete fields. The browser error for incomplete fields varies across browsers but can be customized. Using CSS pseudo classes like user invalid and user valid, input validity can be visually indicated without JavaScript, showing red borders for invalid inputs.

Custom error messages are common in applications and can be integrated into form validation. Exploring how to add custom error messages is the next step. By leveraging these techniques, such as use action states, CSS pseudo classes, and custom error messages, form validation and submission can be enhanced. These methods streamline the validation process, reduce the need for excessive use states, and improve the user experience without relying heavily on JavaScript.

This is a simple React form. We're only using use action states to throw the form action into it. And then we only have inputs that the name and ID, and then we only add the required feed. So each time we add the required attribute, we are triggering the custom validation API. So now if I should try to write something and say, or just type my name and try to submit it, you see that the name feed is valid, but every other field is showing a validation error. And if you notice, this is the browser error that typically happens when you use an HTML form. And so this error might look different on different browsers, which is fine. So we'll see how we can customize this to fit our needs.

And then for the borders itself, we're using a tiny bit of CSS, which is the user valid and user invalid pseudo classes to check if the input is valid. That is why we're throwing the errors here. You can see that the borders are red. So still we've not tried any JavaScript yet. We've not introduced anything like JavaScript. It's just the browser doing this. So how about in a situation where we want to add our own custom error messages? So typically in an application, you will have your own custom error messages as well. So let's see how we can do that.

So the cool thing is that the constraint validation API also gives us more access to do whatever we want to set up our own custom messages, and also to use it in the way we want. So this is where we will start to introduce tiny bits of JavaScript, but still the browser is the one handling how they have a workload for us. So the first thing we'll do is we'll check the form and we'll check if during the on invalid state, we want to set a custom validity to be our own custom messages. So I currently have a function here that says format error. And what this format error function does is it maps every input that we have on the field into a custom error message. So the custom error message would look like this. So we're checking the feeds to see if it's valid or if it's required and stuff like that. And then the next thing we can do with this is that we would then need to use on submit event to check when the user submits it and try to validate the feed and when the feeds are validated, we can then also trigger our own custom error messages.

So the first thing we'll do is we'll check the form and we'll check if during the on invalid state, we want to set a custom validity to be our own custom messages. So I currently have a function here that says format error. And what this format error function does is it maps every input that we have on the field into a custom error message. So the custom error message would look like this. So we're checking the feeds to see if it's valid or if it's required and stuff like that. And then the next thing we can do with this is that we would then need to use on submit event to check when the user submits it and try to validate the feed and when the feeds are validated, we can then also trigger our own custom error messages.

And so this would also work as well with state management and all that. We would need to import state management. Put in mind that we are not importing state management to manage the form itself, but we're just using it to manage errors as well, which means that we have fewer renders. Also, the form is working fine without using useState all over the place. With this in place, we would then set the error so that we can re-render the component if an error changes. The next thing we need to do now is we can now do the typical errors that name and throw a paragraph all over the place as well. If I should try to validate the feed now, you see that the name is required and this sort of handles the validation errors as well. With this, we've been able to throw a lot of weight to the browser to handle a lot of things for us without using any library in React.

Why should we build forms like this? What are the benefits that come along with building forms using this approach? By default, it's accessible by default. So all browsers, screen readers will be able to announce most of the errors automatically without you needing to handle many of the things yourself. The area invalid and area valid can be set by the browser without using JavaScript. With the introduction of React 19, it helps to preserve the native semantics of building forms. You write lesser JavaScript, which results in a faster platform. Fewer re-renders mean you have uncontrolled inputs, leading to better performance. As much as this approach has many benefits, there are also some downsides, which we'll discuss as well. Having fewer re-renders means React does not work during typing, resulting in uncontrolled inputs and improved performance in React forms.

So this makes a lot of sense when building forms that are really accessible and that works well without breaking in production. And the best part is you write lesser JavaScript. So the less JavaScript to pass, the faster your platform is, the faster your application, the faster the website that you're building. And so you end up with having a lower JavaScript bundle at the end.

But as much as all of this has a lot of good benefits, there are also some downsides as well, which we'll talk as well. But let's talk about the last benefit of it is that you have fewer re-renders, which means that React do not really work during typing. So fewer re-renders means you have uncontrolled inputs. So when you have uncontrolled inputs in your React form, you have fewer re-renders, which means more performance as well. So each time a user types something, it doesn't re-render or sort of like trigger things, trigger the re-render process again to sort of impact your performance. So fewer re-renders, more performance as well.

So there are a few downsides that come along with doing forms this way. But then when I was preparing this talk, I sort of compared the production bundle size of all of the React form libraries and also with building React form with just web APIs and React 19. So for me, we had 18 kilobytes. Also for React hook form, we had 10 kilobytes. But for web APIs with use action state, we have 1.6 kilobytes. So there's a huge difference there if you think about it. What are the downsides of building forms like this? Well, there are a few trade-offs that you can notice when building forms in this way. One of them is you cannot add and remove dynamic field inputs.

One of them is you cannot add and remove dynamic field inputs. And so you still need to handle this manually using JavaScript or using a framework or something or using a library or something like that. So for multi-step wizard form, it doesn't handle cross step validation out of the box. You need to have your own state management and you need to wire things on your own. So you need to handle this manually. The browser cannot handle multi-step forms for you out of the box. And then you cannot run async validation with the browser alone. So you need to write some custom JavaScript to handle this, which we've already been doing before. So it's not really like a new thing. We can still do it the way we've been doing it as well. And then also for performing complex cross feed validation, where you need to check one input with the other, you still need to write your own custom JavaScript. So all of this is not new if you write a lot of React code, which is fine as well. And I think the biggest thing I would note is that it doesn't support TypeScript out of the box. So you need to write TypeScript support if you want to build forms using the web native APIs as well.

If you would like to try this out, if you advice I would like to give, if you want to try this out during by the weekend. So a few things you could do to make sure that, okay, you're able to build form using the web APIs alone and just make sure that your forms are very lightweight. You can start small and migrate gradually. So this weekend, what you can do is first try building forms with web native APIs first. So use the use action state with the constraint validation API for your new forms and see how it works. If they serve your need fine and good, you don't need to use a third party library. And you can start with converting very simple forms first. Forms that have low risk, but high visibility, for example, your login forms, your contact form, your newsletters, and those kinds of forms. You can start with those and migrate them as well. And the cool thing is you can also create an abstraction. So create a shared hook that use use form action hook that's created a shared hook, like the use form action hook that uses web APIs to sort of like implement all of this feature. So you create an abstraction to use in your forms. And if you feel like you can't do all of that, you can also use an AI agent to assist you. AI agents are quite good with web APIs and so they can help you write and optimize your native form code. So it's well optimized for usage.

So at the end of the day, I want to say something that, oh, it's still the web. So the platform, which is the web platform that we all use most of the time already has everything that we need to build full-blown production applications. So by default, web APIs should be your go-to. And only if they don't serve your need, that is when you should think about using a third-party library or a third-party form. So thank you very much for listening to my talk. And yeah, you can find me on social media at Code Jagaban if you have any questions and stuff like that. So thank you all and see you next time. Bye.