We can also do things like enforcing best practices. So react in view, I can speak to I have experience with and they provide methods for you to require certain things when you implement things like like an input. So saying that every input requires a label or a name or things like that. You can enforce. There’s also things that we know are required for every input such as IDs. But we don’t have to be as strict with we can we can generate those and have kind of a fallback for developers. So let’s look in a view example of what that might look like, is I have a component here where I’ve defined, you know, here, just the props. And with these props, I can say that we have a label, and we have a name prop that this component expects. And I can say that both of those are required, as the developer creating the component. I have no idea how this input is going to be used. But as the developer consuming it, you’re going to be required to give me those fields because for a, for a fully accessible and quality input, I need them. I also need the ID of an input in order to maintain those ARIA attributes. But I don’t necessarily need you to give me an ID, you can, you may if you want, and I’ll take it, otherwise, I can fall back to generating randomly created one. Now this input, we may want to add validation logic to anytime that experiences a blur event. So we and then that validation logic, we want to show some errors for so we can start with some reactive properties of tracking error, an array of errors. And then on that blur event, we can tap into the validity state of that input and check whether it’s invalid or not. For each of those properties that we saw before, we can loop over them, see what the property check what the property is check the whether it’s valid or invalid. If it’s valid, we can move on to the next property, if it’s invalid. In this example, we’re looking at the range underflow property which corresponds to the min attribute. So if the min attribute is invalid, we can push to our error object, hey, this, this input must be greater than whatever the minimum attribute is. And we can push that error to our reactive error array, and then present that in the UI. So looking at the UI for this component, it might look something like this, we might have the label that’s associated to the input through that ID, we might check whether this is a required a required input or not based on the attributes, and if so maybe put a little red asterisk next to the label. We’ll have our input, of course that has our validation event handler, and the ID and everything else, an aria described by. And then we might have our UI for showing those error messages. And that can be associated with the input through the ARIA described by Attribute generated with the ID or, you know, based off of the ID, and has a role of alert. There’s a little bit more this is this example is inspired from a an input component in the utensils library, which you can check out later. Now besides the input, we can also create a component for our form. And our form component might have a submit event handler that checks the validity of the form kind of like we saw before using the check validity method. And if the form is invalid, we can, you know, automatically focus and scroll to the first invalid input. But then, in addition to the same features that we’ve discussed, and kind of adding those to a component, we have new features available, which are custom event emitters. And this will make more sense in a moment. But we can base basically create custom events for when the form is invalidly submitted. And when the form is validly submitted. This components markup is a lot simpler. It’s just a form, it falls back to a POST method for security reasons, which I don’t have time to get into now. It implements a slot in React, this corresponds to the component children. To make life easier for all the development developers, maybe it includes a submit button, which is not customizable in this case. But you can imagine.
Originally published on austingil.com.