Before we start creating our own inputs, let's quickly look at the form kit docs in order to see what else is available. Under docs and then inputs here, you can see a wealth of options. We have an autocomplete, which is a pro input. So that's worth noting here that we do have a collection, a combination of pro and free inputs to use.
So there's also a button, a checkbox, color picker, and just a number of different things here. There's a text area, there's time, there's week. Yeah, there's really a lot to choose from. Okay, now let's go and get hands-on in the code.
view, and I'll replace this Nuxt welcome component here with a brand new shiny form kit component. Let's start out with a regular old text input. After I hit save, You'll notice my IDE automatically added the closing tag for me, and over on the left-hand side, we do have our input displayed to the page. Let me zoom in just a little bit so you can see things more clearly.
Now, so far, what we've got really isn't that impressive, right? It's just a regular old text input. However, now we could create other kinds of inputs with the same exact API. that typically require an entirely different tag.
For instance, we could add in a select here. And how about a text area? Nice. Over on the left-hand side, you can see that we do in fact get the proper inputs.
To make things even shorter, we can make these all self-closing component tags, like this. Yeah, that works just the same. Having this common API for all of our inputs, makes it super easy to remember how to create the fill markup. However, it also makes dynamically changing out the types of the fields a lot easier, since all you have to do is bind the type property.
And sometimes a dynamic fill type is a super useful feature. Let's up the game on our text input here though, just a little bit, by taking a look at some of the other prompts that we can provide. I've got that already copied to my clipboard, so I'll just paste that in. Immediately, you can see the output update here on the left.
And now we have an input label, some help text, even a invalid message here. This is powered by the label prompt and the help prompt as well as validation. But for some reason, our icon is not showing up. Let's try to give the page a quick refresh.
Nice, that's better. Now we have the icon present, and you'll notice we also have the value that was provided as the default value here. Also, our error message has now disappeared. That's because we have some valid input.
As soon as I remove this valid input though, and then blur the field, you can see that we get a message saying that the field is required. We'll learn more about how to write validation in a later lesson. But for now, just notice that we do have a required rule defined over here in our validation prop. That's pretty cool and pretty straightforward.
What's really great is that all these single line prompts are producing a number of different pieces of markup that you'd normally have to write yourself. Let's take a look in the DevTools and see what's actually being generated under the hood. For our username field here, we have a wrapper div surrounding the whole thing. We also have a label.
We have an intersection here, which wraps everything that's a part of the actual input. We have markup for our help message, as well as markup for the validation message. Notice each of these have classes that are prepended with the word formkit and then a dash. In the FormKit framework, these are all known as sections of your input.
You can target these different sections based on their respective class, and then style them however you'd like. Or you could even customize this class name to match up with the design system of your choice. To customize the class, you can add the section that you want to target. Let's do Enter, and then provide the keyword.
class. Then whatever value I add here will be added to that section. Nice. You can also customize the markup of each section with slots.
For instance, maybe you'd like the help text to display as a tooltip instead of underneath the input. That might look something like this. First we'll add a closing tag. Then we'll use the template tag in order to target a particular slot.
The slot that we'd like to target is called Label, and it receives access to the context, which gives us more information about that particular input. Now I'll go ahead and spit out the label that is already displaying, then we'll add a question mark. You can think of this as our tooltip icon, but we're not really going to get things working for a tooltip right now. This is just kind of an example of how you can use the slots.
Then finally, I'll create a span and print out the help text within it. Once I hit save, if I come over here to the browser and refresh the page, sure enough, we now have the help text appear along with the username. Of course, it's not working like a real tool tip. Like I mentioned, we aren't actually making that functionality yet, but I think you get the idea.
Now, we still get the help text underneath the input as well, but we can easily take care of that by targeting the help slot and then just rendering nothing in it. Awesome. In this lesson, you saw how a single FormKit component can power all sorts of different inputs, all with a nice clean interface. But even with the simple interface, we have the power to customize FormKit exactly to our needs.
based on the sections and the section classes, the ability to customize those section classes and even customize the markup per section with slots. Before we start creating our own inputs, let's quickly look at the form kit docs in order to see what else is available. Under docs and then inputs here, you can see a wealth of options. We have an autocomplete, which is a pro input.
So that's worth noting here that we do have a collection, a combination of pro and free inputs to use. So there's also a button, a checkbox, color picker, and just a number of different things here. There's a text area, there's time, there's week. Yeah, there's really a lot to choose from.
Okay, now let's go and get hands-on in the code. view, and I'll replace this Nuxt welcome component here with a brand new shiny form kit component. Let's start out with a regular old text input. After I hit save, You'll notice my IDE automatically added the closing tag for me, and over on the left-hand side, we do have our input displayed to the page.
Let me zoom in just a little bit so you can see things more clearly. Now, so far, what we've got really isn't that impressive, right? It's just a regular old text input. However, now we could create other kinds of inputs with the same exact API.
that typically require an entirely different tag. For instance, we could add in a select here. And how about a text area? Nice.
Over on the left-hand side, you can see that we do in fact get the proper inputs. To make things even shorter, we can make these all self-closing component tags, like this. Yeah, that works just the same. Having this common API for all of our inputs, makes it super easy to remember how to create the fill markup.
However, it also makes dynamically changing out the types of the fields a lot easier, since all you have to do is bind the type property. And sometimes a dynamic fill type is a super useful feature. Let's up the game on our text input here though, just a little bit, by taking a look at some of the other prompts that we can provide. I've got that already copied to my clipboard, so I'll just paste that in.
Immediately, you can see the output update here on the left. And now we have an input label, some help text, even a invalid message here. This is powered by the label prompt and the help prompt as well as validation. But for some reason, our icon is not showing up.
Let's try to give the page a quick refresh. Nice, that's better. Now we have the icon present, and you'll notice we also have the value that was provided as the default value here. Also, our error message has now disappeared.
That's because we have some valid input. As soon as I remove this valid input though, and then blur the field, you can see that we get a message saying that the field is required. We'll learn more about how to write validation in a later lesson. But for now, just notice that we do have a required rule defined over here in our validation prop.
That's pretty cool and pretty straightforward. What's really great is that all these single line prompts are producing a number of different pieces of markup that you'd normally have to write yourself. Let's take a look in the DevTools and see what's actually being generated under the hood. For our username field here, we have a wrapper div surrounding the whole thing.
We also have a label. We have an intersection here, which wraps everything that's a part of the actual input. We have markup for our help message, as well as markup for the validation message. Notice each of these have classes that are prepended with the word formkit and then a dash.
In the FormKit framework, these are all known as sections of your input. You can target these different sections based on their respective class, and then style them however you'd like. Or you could even customize this class name to match up with the design system of your choice. To customize the class, you can add the section that you want to target.
Let's do Enter, and then provide the keyword. class. Then whatever value I add here will be added to that section. Nice.
You can also customize the markup of each section with slots. For instance, maybe you'd like the help text to display as a tooltip instead of underneath the input. That might look something like this. First we'll add a closing tag.
Then we'll use the template tag in order to target a particular slot. The slot that we'd like to target is called Label, and it receives access to the context, which gives us more information about that particular input. Now I'll go ahead and spit out the label that is already displaying, then we'll add a question mark. You can think of this as our tooltip icon, but we're not really going to get things working for a tooltip right now.
This is just kind of an example of how you can use the slots. Then finally, I'll create a span and print out the help text within it. Once I hit save, if I come over here to the browser and refresh the page, sure enough, we now have the help text appear along with the username. Of course, it's not working like a real tool tip.
Like I mentioned, we aren't actually making that functionality yet, but I think you get the idea. Now, we still get the help text underneath the input as well, but we can easily take care of that by targeting the help slot and then just rendering nothing in it. Awesome. In this lesson, you saw how a single FormKit component can power all sorts of different inputs, all with a nice clean interface.
But even with the simple interface, we have the power to customize FormKit exactly to our needs. based on the sections and the section classes, the ability to customize those section classes and even customize the markup per section with slots.