In older versions of Laravel, if you ever needed to validate an array of items, for example, the User can enter a number of email addresses, and you want to make sure that all of those email addresses are formatted properly. Well, that actually ended up being kind of a pain. But nope, not anymore. Let me give you a little example. And we'll use this welcome page. And let's see, let's get rid of all the stuff there. I'm going to pull in Bootstrap, just to give ourselves some formatting. And let's simulate something like, how about, invite up to five people.

I'm going to pull in Bootstrap, just to give ourselves some formatting. And let's simulate something like, how about, invite up to five people. Maybe some kind of new app you're working on. Okay, so we'll have a form with our CSRF field. Let's set up a text field for the email address. Now, in real life, I would use an email input. Or, I'm sorry, I would set the type to email. And that just gives you some extra browser validation. But I just want to get around that for the purposes of the demo. So we'll stick with text.

But I just want to get around that for the purposes of the demo. So we'll stick with text. So, yeah, pretty standard stuff you've seen many times, right? So now let's say you can invite up to three people. So I'll copy that. Now, what if we want all of these email addresses to be passed through as an array? And that way you don't have to do things like this. email1, email2, and then you have to access them separately from your php. It's kind of annoying, right? So instead, we can just use this array-like syntax.

It's kind of annoying, right? So instead, we can just use this array-like syntax. However, for your IDs, you would want to make those unique. And, of course, update your for attribute as well. Okay, so now we can add a little submit field. And why don't we view this in the browser? Now, right off the bat in Laravel 5.2, if you're working along, yeah, you'll get this. Session store not set on the request. And that's because of, well, this section right here. Now, let me show you something.

And that's because of, well, this section right here. Now, let me show you something. Let's go over to our HTTP kernel. And you'll see we have this web middleware group. In fact, middleware groups are new in 5.2. We just haven't talked about it yet. And you'll see it handles a bunch of things like starting up the session, adding cute cookies to the response, sharing errors. So this is where you can access errors within any view. And, in fact, if you want to see how that works, share errors.

So this is where you can access errors within any view. And, in fact, if you want to see how that works, view share. There we go. Yeah, you can see it's pretty basic. So we just call view share. We reference the key, and then we fetch the errors from the session bag or default to a new view error bag. So, yeah, that's how you get access to an errors variable on every single page. But, yeah, anyways, we're going off track. We have this web middleware group, but if I go over to my routes file and we scroll down,

But, yeah, anyways, we're going off track. We have this web middleware group, but if I go over to my routes file and we scroll down, yeah, you'll see that we didn't nest our route within here. So let's do that. Let's grab that and just paste it in here so we get all of that stuff out of the box. Okay. If I go back to Chrome and give this a refresh, it should load. There we go. And now let's see. If we submit this form, what do we want to have happen?

And now let's see. If we submit this form, what do we want to have happen? Well, let's do this. Why don't we say, yeah, I can just post to the home page. So why don't we set up a new route for that? Why don't we say, so let's see. If we post to this home page, why don't we just dd all of the $request params for now? So let's grab that and let me go ahead and import that. Yeah, there we go. All right.

Yeah, there we go. All right. So we pull it in at the top and then we say when we post to this home page, yeah, just dump all of the request params and let's see what we have. So we have no validation in place just yet. Let's enter some gibberish here. Yeah, now because we're using that array syntax, you'll see they're all nested as an array. Okay. So now let's move on to the new cool thing in 5.2. Just a small thing but actually pretty useful.

So now let's move on to the new cool thing in 5.2. Just a small thing but actually pretty useful. I want to say let's make sure that each item here is formatted as a proper email address. All right. So here's how we could take care of that. First, let's do it the manual way and then we'll use the validatesRequests trait in a controller. So the traditional way is to build up a validator. So we could say Validator::make. We pass through all of the request params and then we pass through an array of our rules. Now, we have the email key, right?

We pass through all of the request params and then we pass through an array of our rules. Now, we have the email key, right? We can see that here. But if we now want to say, well, I just want to apply it to all of them here. Well, just do email.* and that's it. So we can say those are required or those should be formatted as email, whatever is appropriate. Okay. So we'll say save that to validator. And then finally, if the validator fails, then in that case, we should return back with the input and also with the errors. Okay.

And then finally, if the validator fails, then in that case, we should return back with the input and also with the errors. Okay. Otherwise, return validation successful. Invite those fools. Sweet. That looks good to me. All right. Let's try it out. Once again, we enter our gibberish here. Submit.

Once again, we enter our gibberish here. Submit. And it looks like it's expecting a string but we're feeding it an array. And here's why. Back in my view, yeah, it's because of this section right here. We switched over to this array syntax but we're still trying to fetch it like it's a single item. So yeah, in this example, you would do email, get me the first one, then the second one, and then the third one. Okay. If I give that a refresh, do one more time, and there you go. We redirected back.

If I give that a refresh, do one more time, and there you go. We redirected back. Whereas if I were to repeat this, there you go. All right. So mainly, that's it. We're going to keep working on this but that's the gist of it. We can now, in my routes file, scroll down. We can now use this * syntax to say validate every single item within this array and make sure that we pass something and also they are formatted properly. So if we wanted to provide some error messages, we could do something like this.

Okay. So now we enter a gibberish here and it will redirect back but now we have some messaging where valid. But notice, well, yeah, it doesn't necessarily make sense in this case. It's not overly readable. So what we could do, if we go back to our routes file, and in fact, let's just get rid of that entirely. Okay. But yeah, what we could do is pass a custom array of messages as the third argument. So for example, we could say email.* would be this address must be formatted properly. Maybe something like that. Okay.

Maybe something like that. Okay. So now if we submit it again, you'll see it now reflects the changes. Now, of course, remember, you don't have to do all of this stuff if you don't want to. For example, let's create a controller. I don't really have anything here. Why don't we call it InvitationsController? Okay. And if we open that up, we could say right here when we post or when we store our invitations, once again, that will accept the request.

And if we open that up, we could say right here when we post or when we store our invitations, once again, that will accept the request. But now because all controllers, if I switch over real quick, because all controllers implement this trait or use this trait, we have a validate method that takes care of so much of the legwork. So I'll show you. We could just say this, validate the request using the given rules. And now once again, just to repeat, required and be formatted properly. Otherwise, all items are valid email addresses. Yeah, it's really nice.

All of that stuff you don't really have to do anymore. So let's replace that with, what did we call this? InvitationsController at store. Yeah. So now here's what our method looks like. Just a single call to validate. And this is not new to 5.2, by the way. It's new in Laravel 5.0, I believe, or maybe 5.1. In any event, it's incredibly useful. Now, of course, remember, if you do want those custom error messages,

In any event, it's incredibly useful. Now, of course, remember, if you do want those custom error messages, then make sure you override this. Anyways, let's try it out. Enter a bunch of gibberish and then a proper address. Submit, and yeah, now it's working. So if we fix that, run it, all items are valid, and that's brand new in Laravel 5.2.