All right, so now we should talk about validation. At the moment, there's no rule at all that says, Hey, John or Jane, you gotta type something into this text area. So that means can we just submit the form with nothing? Yes, we can. So notice it's still gonna fail, but it reaches the point of running an SQL query and at that point we fail because description cannot be null in the database and we're trying to provide null. But yeah, if you think about it, that's really bad.

and we're trying to provide null. But yeah, if you think about it, that's really bad. We reached all the way up to the point where an SQL query was performed before we realized, hey, there's a problem here with the user's input. So we're gonna solve this in two ways. We will solve it service side as well as client side. Alright, let's start with service side. So I'm gonna go into my idea controller

Alright, let's start with service side. So I'm gonna go into my idea controller and yeah, right here when we hit the store action, this is where the user of course submits the form and we should persist the idea in the database as you see here. So it sounds like the only field that we need to validate right now is description. So here's how we have a couple options. First, you learned about that request helper.

So here's how we have a couple options. First, you learned about that request helper. Uh, many episodes ago we could say request validate. However, you also can see that when we generated or scaffolded this controller, we can also optionally request an instance of request from the controller action, which means instead, rather than referencing a helper function, that will resolve the request. Uh, instance, I can instead access it directly

that will resolve the request. Uh, instance, I can instead access it directly and then call validate, but it's still the exact same thing. So you're free to choose whichever option you like most. Alright, so I'm gonna validate the form submission basically. And here's what we're gonna do. Which field are we validating? Description The text area with the name of description. Alright, so what are the rules? Is it required?

Description The text area with the name of description. Alright, so what are the rules? Is it required? Yes, at bare minimum it's required, which means it can't be omitted. Okay? So now check this out. If I were to switch back to my browser and we give this another shot, hmm, I'm submitting it and it just seems like the page reloads. Alright? So we're not providing any feedback to the user, but in fact our validation is working.

Alright? So we're not providing any feedback to the user, but in fact our validation is working. Alright, so here's what's going on right now. If I switch back right when we hit this controller action, we perform validation, we take whatever was submitted there and if you want, we can just check it out right now. Request, uh, all, let's see what we are providing to the server. Alright, so we are providing the, uh, the token which we can ignore,

Alright, so we are providing the, uh, the token which we can ignore, but then we're also providing description of null and then we say, well make sure that description is required. You can't give us null and that's not allowed. So in this case it fails and here's what's happens. This is kind of the secret sauce. Larva will handle the process of automatically redirecting back to the form

Larva will handle the process of automatically redirecting back to the form because that's almost always what you wanna do in these situations. A if the validation fails, go back to the form and provide some feedback to the user. Okay, but now what about these situations? If I switch back, what if the user tries to submit the form and they just provide gibberish or something like this one letter.

and they just provide gibberish or something like this one letter. Is that a valid idea? No, almost certainly not. But we satisfied the required validation rule. So sure enough we created an idea that just says Q and maybe we don't want that. So let's delete that. And if you want, we can append to our validation rules. We could say yes, it's required and you have to give us a minimum number of characters.

We could say yes, it's required and you have to give us a minimum number of characters. And this just depends on what you want. Um, is a three, is it, uh, do you expect at least a sentence? Do you wanna say at least 50 characters? Whatever you want. Maybe we'll start with 10. If you don't even give us 10 characters, there's, there's probably something going on here. Okay, well now if we come back

there's probably something going on here. Okay, well now if we come back and we try again, so we try Q once again and we can tell it failed validation and it redirects back and yeah, I promise once again we're gonna provide some feedback in just a minute, but this is really cool, right? So now we can tell if uh, if we reach this point, that means our request data is valid and we can trust it if we don't reach that point, uh, in this case, that means validation failed

and we can trust it if we don't reach that point, uh, in this case, that means validation failed and Laravel automatically redirects back to the form. Okay, so why don't we handle displaying validation errors now? Like, so let's go into our create view and yeah, you can do it wherever you want and there's a couple options, right? Uh, and you've probably seen this many times. Sometimes if validation for a form fails, maybe

Uh, and you've probably seen this many times. Sometimes if validation for a form fails, maybe below the button in red text you see a list of all of the errors in other situations maybe directly below the input. If validation fails, you see it, um, in line basically. So you can do whatever you want. Why don't we do it in line, so right here for the text area. Alright, so you know what, I'm gonna show you two options here

Alright, so you know what, I'm gonna show you two options here for displaying an error message, uh, a long form way and then a condensed blade directive option. That way you kind of understand and appreciate both, uh, options. So first up, as it turns out, Laravel makes this errors variable available in all of your views. So you never have to check if it exists,

available in all of your views. So you never have to check if it exists, it will always be made available. And in the event that you have failed validation, this errors object will be populated with those, uh, validation messages. So in our case, I wanna see, well do we have a validation error for description so we can use the has method. Do we have anything for description in that case?

so we can use the has method. Do we have anything for description in that case? Uh, at least to start, let's just say there was uh, an error, all right, so if I come back, let's fail the validation, we submit it and sure enough we see it. So as it turns out, validation messages are flashed to the session and by flash I just mean it will be available for the next request and then it gets cleared. So notice if I refresh the page, well that's a new request

for the next request and then it gets cleared. So notice if I refresh the page, well that's a new request and they're no longer available, right? And this is exactly what you want in these situations. If validation fails, you basically wanna say, all right, flash something to the session so we can display it on the next page load, but then we can, we can erase it. Basically we don't need it any longer. Okay? So we could do this, we could say make it extra small

Basically we don't need it any longer. Okay? So we could do this, we could say make it extra small and red and now let's do it. Yeah, a little better. Maybe MT one, you know, whatever is appropriate, uh, for your website, okay? But now of course there was an error, we've all encountered these, they're incredibly unhelpful, right? So let's provide more specifics.

they're incredibly unhelpful, right? So let's provide more specifics. If I come back, I'm gonna replace this with errors. Um, why don't we do the first error message for description. So this is gonna give me, and, and keep in mind there could be more than one validation error for um, a field. So in this case, we're just gonna show the first one, that's fine. So if I come back, try it again,

show the first one, that's fine. So if I come back, try it again, we can see the description field must be at least 10 characters. So what we can see is it's failing this validation rule, but what about if it fails this validation rule? Well then the message will change, right? So if I leave it empty, now that rule fails and then if we add one the required field, uh, or rule passes, but now the men 10 rule, um, is failing

and then if we add one the required field, uh, or rule passes, but now the men 10 rule, um, is failing and that message will update automatically. Okay? So let me show you something. If you visit lael.com/stocks/validation, scroll down and you'll see a list of all available validation rules. And yeah, it's a massive list. It's not like you have to memorize all of these, just reach for it. Whenever you have a particular validation rule, uh,

of these, just reach for it. Whenever you have a particular validation rule, uh, that you need, and you know what, whatever it is you need is probably gonna be listed here. If it's like hey, uh, the string the user provides has to be represented in this list, one of these items, um, it should be an image of this size and no greater than this size. It should be a number between this and that. Um, it should be a string with a maximum.

It should be a number between this and that. Um, it should be a string with a maximum. And you get the idea it should be a hex color. Whatever it is you want is almost certainly represented here and you can have a look at those. So the main ones will be like minimum characters, maximum characters, alpha numeric maybe for passwords confirmed, which means the user has to type their password twice maybe, and you wanna make sure that those two fields match email.

to type their password twice maybe, and you wanna make sure that those two fields match email. This must be a valid email address. You get the idea. Alright, very cool and good to know. So be sure to bookmark this page. Alright, so anyways, if we switch back to our view, let me show you a shorthand. Now, uh, this is a very common pattern so we can simplify it by instead reaching for ariel's error directive. So we're gonna give it the name once again.

by instead reaching for ariel's error directive. So we're gonna give it the name once again. And don't forget this name is coming from right here. It's the name attribute on your input. So let's add end error. And now within this blade directive, within the contents there you will have access to a new message variable, uh, feels like magic, but again, don't forget behind the scenes, this is compiling down to vanilla PHP.

but again, don't forget behind the scenes, this is compiling down to vanilla PHP. It's just a little bit of sugar. Uh, so this isn't really magic, it's being made available, you just don't see it behind the directive and that's cool. Alright, so yeah, it's just a little bit easier to prepare. Come back, try it again and we're gonna get the exact same thing as we did, uh, previously. Okay, next, while we're here, you can have fun

as we did, uh, previously. Okay, next, while we're here, you can have fun with components, right? So far we've only created one component, but you can create one for anything you need. So if you don't wanna duplicate your error, um, your error message in terms of the size, uh, the HTML, maybe you have a little icon. All of that can go into a reusable component. So if you wanna see that really quickly,

All of that can go into a reusable component. So if you wanna see that really quickly, create a new component, call it error blade PHP. Let's take everything. This is what I usually do, paste it in and then I just swap out, um, whatever I need to. So in this case, it seems like the only dynamic section should be description. Sometimes it'll be names, sometimes it'll be email. So this should be whatever the name is,

Sometimes it'll be names, sometimes it'll be email. So this should be whatever the name is, which means that should be our prop. So let's declare props at the top and say you gotta give us a name. Once you do, we will use that and assume that this represents your validation error. And that's it. You now have a reusable component where we have, uh, isolate, uh, isolated the tailwind classes and the markup

where we have, uh, isolate, uh, isolated the tailwind classes and the markup and anything else you've defined, uh, for your error message. So if I were to come back now we can just say x slash error or, or or dash error. Alright, what is the name description? So yeah, you can imagine you can get pretty clean here if you're thoughtful about how you define these. Come back, refresh, do the exact same thing

you're thoughtful about how you define these. Come back, refresh, do the exact same thing and our component is working, but now we have a super handy dandy, uh, error component that we can reach for. Cool. Now, um, actually lemme show you one more thing On that note, as you can imagine, you might have many components related to your forms. For example, maybe you have a component for your text areas, maybe you have a component for, uh, your messages.

For example, maybe you have a component for your text areas, maybe you have a component for, uh, your messages. Anything that you can imagine reusing across all of your forms is probably unlikely a good candidate for being extracted into its own component. So yeah, if you wanted, um, what you might wanna do is within your components directory, create a new directory for your forms and then you could take error. So this makes it a little more clear that okay,

and then you could take error. So this makes it a little more clear that okay, this is the error component for a form rather than maybe like a 4 0 4 page an error or a status error. This is clearly the form error page. Okay? But now if I switch back, you'll see a squiggly line here. This isn't quite right. So whenever you have a component nested within a parent folder, reference the parent folder's name then dot.

whenever you have a component nested within a parent folder, reference the parent folder's name then dot. So once again we're using that dot notation and then the uh, the name of the component itself. So folder name, dot component name. So now just to prove it to you, we're gonna get the exact same thing, but this is very common in the wild and uh, I would recommend it to you. Cool. Alright, so if I switch back to my controller,

and uh, I would recommend it to you. Cool. Alright, so if I switch back to my controller, you know what, I think this is great and in fact this is what I personally do most of the time. I really like seeing the validation directly within the controller. Uh, it fits my head, it fits my personality. However, maybe it doesn't fit your personality. So if you are the type where you might prefer to place this validation within its own dedicated class,

So if you are the type where you might prefer to place this validation within its own dedicated class, well I'm gonna show you how to do that in the next episode.