Here, we have a form that accepts an email address. At the moment, it does nothing, but let's learn how to submit the form, read the input, and then fire off an email to that user. Okay. Now, if we look at the Vue, here's what we have. A pretty simple form. We have our email input, and then a button to submit the form. However, notice at the moment, it's not submitting anywhere. Okay. If I switch to my routes file, this page is responding to an endpoint of contact. Wiring Form Submission 0:26Okay. If I switch to my routes file, this page is responding to an endpoint of contact. So how about when you submit the form, it submits a post request to the same endpoint and then hits a store action. Okay. So, let's add our store action, and here is where we send the email. Okay, but a couple things first. You know that we can read any input by using the request helper. So sure enough, if I were to die and dump that email address, and if I quickly switch back to our Vue and submit a post request to slash contact, sure enough, give it a refresh, Adding Email Validation 0:55So sure enough, if I were to die and dump that email address, and if I quickly switch back to our Vue and submit a post request to slash contact, sure enough, give it a refresh, we will see that value right there. Okay. But, if I provide gibberish, we still see it. So if we're not careful, we will send an email to an invalid email address. Okay. Let's fix this with validation on the front end and the back end. We'll start with the back end. In our controller, you should already know that you can validate the request like so.We'll start with the back end. In our controller, you should already know that you can validate the request like so. The email address is both required and should be a valid email. So now, if this validation fails, we'll never reach this point. Laravel will automatically redirect back to the previous page or form. Okay. Now, if we try it again, it redirects back, but it doesn't provide any feedback. Okay. Let's read the errors object. So again, this is all a recap at this point. Displaying Validation Errors 1:57Let's read the errors object. So again, this is all a recap at this point. Here's our input. Right down here, let's say, with red text and very small, we will spit out the error for the email input. Now we could read the errors object like this, or you can use the helpful directive like this. I want to read the error for the email. And when we use the directive in this way, we will then have access to a message variable. And this, of course, will contain the message for the error.And when we use the directive in this way, we will then have access to a message variable. And this, of course, will contain the message for the error. Okay. So now, if we try it again, it redirects back, and now we have a little more feedback. And that's great. So now we have two levels of validation. Okay. So now, we can move on to sending the email. And there's a couple of ways to do this. First, let's get rid of all of this. Sending Email via Mail 2:48And there's a couple of ways to do this. First, let's get rid of all of this. The simplest way to send an email is with the mail facade. I'll pull that in, illuminate support facades mail, and then I will use this raw method here. We're sending a raw text email. It works. Now, as the second argument, we'll pass a closure here where we can define the parameters of the message. For example, who is the message to?of the message. For example, who is the message to? Well, the person or that email address we provided. Next, what is the subject of the email? We'll just say, hello there. And you get the idea. Finally, once the email has been sent, why don't we redirect back to the contact page? And I think we're ready to try. So we'll come back to Firefox, reload the page, provide an email address, and if we submit it, it does redirect back to this page, but again, notice there's no feedback. Inspecting Logged Emails 3:32So we'll come back to Firefox, reload the page, provide an email address, and if we submit it, it does redirect back to this page, but again, notice there's no feedback. We'll get to that in a minute, but first, let's try to read the email. So how was it sent? Well, don't forget in your environment file, right down here in the mail section, we specified that the mail driver is log, which means we're not really sending an email. We're simply logging the message to a file. Now you'll find that if we open the tree view in the storage logs directory, and there's our log file, and we have our email. We have our subject, who it's to, as well as the body.our log file, and we have our email. We have our subject, who it's to, as well as the body. But now real quick, where was hello at example.com defined? That's the from address. Well, of course, when you send the email, if I switch back, you could define it here, be explicit, but there's also a global email address you can send from, and again, that will be in your config mail file. So if we scroll down, you'll see here it is. Here's the global from address. And again, notice it's defaulting to that.Here's the global from address. And again, notice it's defaulting to that. So if you want to change it, if all emails will come from admin at example.com, then go to your environment file, you'll add it here, and now all future emails will be sent from there. Let's see. One more time. It sends the email, here's the new message, and notice the from has been updated to admin at example.com. So now let's wrap up by providing a little more feedback. Adding Flash Feedback 5:03at example.com. So now let's wrap up by providing a little more feedback. As we saw, we send the email and it does redirect back, but there's no indication that it worked. And this will be super confusing to people. All right, let's add a flash message. So a flash message is basically data that is put in the session for exactly one request. So when we redirect, we can flash to the session like this, with message of email sent. So what will happen is when we redirect back to the contact page, a message key will be flashed to the session, again, for exactly one request.So what will happen is when we redirect back to the contact page, a message key will be flashed to the session, again, for exactly one request. So let's check for it in our view. And we can do it, I don't know, maybe right down here. And we can say, all right, look in the session. Do we have anything for that flash message? If so, spit it out. And we'll close that out. Okay, let's give that another shot. So we fire off an email, it redirects back, and now you have your flash message.Okay, let's give that another shot. So we fire off an email, it redirects back, and now you have your flash message. And of course, we can style this however we want. So how about text green, text extra small, maybe a little margin top, and you know, that's probably fine. Run it, and yeah, that's fine. But alternatively, it's the exact same workflow, but some people will style it to slide down as a little bar from the top. For Laracast, and many other sites, you'll see a little slide out down here in the bottom right.For Laracast, and many other sites, you'll see a little slide out down here in the bottom right. But it's all still the same thing, only CSS differences. We're still reading from the session. So now notice, if I give it a refresh, because we only flashed that for one request, it'll disappear. And that's exactly what we want.
