Okay, next up we have mailables in Laravel 5.3. Think of this as a nice wrapper around the old way we used to do it. And in fact, if you want to stick with the old way, everything's going to work, nothing breaking here. But, yeah, doing mail, send, and then having to pass a view, and then an array of data, and then a closure here, and then sometimes you have to send other data through where you accept the message. You know, it just gets kind of, kind of gross, to be honest. Instead, though, in 5.3, we can just say mail. We're sending this to jeff@example.com, and then we can pass an object to it. So I could say new WelcomeToLaracast(). Much, much cleaner. And now, WelcomeToLaracast is just a very simple class that can be responsible for how we build up the email. So as you can imagine, this is much easier to write and easier to consume versus the old way with the closure and the super long line.

that can be responsible for how we build up the email. So as you can imagine, this is much easier to write and easier to consume versus the old way with the closure and the super long line. Yeah, I like it a lot. So let me show you. In our app directory, by default, you won't see a mail folder, but as soon as you generate a mailable, you will. So we can say php artisan make:mail, and you'll see that we have a new make command for an email. Okay, so why don't we call this, like I said, welcome to Laracast. This is the welcome email that goes out when you sign up for a site. Okay, well now you'll see it gets added to this new mail folder, and if we take a look, very, very simple. The build method is really where you're going to do most of your work. So here's where you can define everything from attachments to overriding who the email is from to setting a number of things. However, in the constructor, yeah, the important thing to understand is that

where you can define everything from attachments to overriding who the email is from to setting a number of things. However, in the constructor, yeah, the important thing to understand is that the views data will now pull from any public properties defined on this class. So probably the easiest way is just to show you. Imagine we have emails.welcome, and I will create that. resources/views/emails/welcome.blade.php, and then we'll say, welcome to Laracast. And then within here, like some lorem text, right? Just a typical email. Okay, well we have defined our Mailable class. We are building it by defining the view here. We don't yet have any constructor arguments, so we'll just leave it like that. And now if I go to my routes/web.php file, here's what we had from the previous lesson, but I can get rid of that. And instead, I'm going to say Mail::to('jeffwayatexample.com')->send(new Welcome()); And let me go ahead

had from the previous lesson, but I can get rid of that. And instead, I'm going to say mail to jeff@wayatexample.com, and then I will say send new welcome to Laracast. And let me go ahead and import that. Okay, does this all make sense? Well, before we can check this out, let's do a quick bit of setup since this is still a fresh application. I'm going to go into my .env file, and you'll see that yes, we want SMTP, and the default host is mailtrap.io. And this is a nice little service that literally traps the email. So if you fire something off to john@example.com, he won't actually receive it. Instead, Mailtrap will intercept it so that you can review the email. It's really great for development. And you'll notice that out of the box, Laravel gives you the host and the port name that Mailtrap will expect for free as a recommendation. So that's great. If I go to Chrome, let's visit mailtrap.io and log in, you can set up a free account,

host and the port name that Mailtrap will expect for free as a recommendation. So that's great. If I go to Chrome, let's visit mailtrap.io and log in, you can set up a free account, just hook it up to your GitHub profile or something like that. And we'll create an inbox called demo. And basically, we're all set to go. So we can see our credentials here, like the username also defined up here. So let's do this. Mail username, Mail password, and done. We're all set to use Mailtrap. It's that easy. Okay, so once again, we hit the home route, and we're going to fire off an email to jeffway@example.com. Using this mailable, that for now just loads the email.welcome view. And that contains this spoiler plate. So I think we're ready to try this out. But it fails because we didn't declare who the email is from. Now, of course, you can do this here. But very typically, you're going to define this within

I think we're ready to try this out. But it fails because we didn't declare who the email is from. Now, of course, you can do this here. But very typically, you're going to define this within your config/mail.php file. And this is pretty standard. So define your default from address, we'll do jeffrey@laracasts.com. And then the default name, Jeffrey Way. So now that will be applied to every single email that your application sends. So if we run it again, okay, we have no feedback, but it should work. And if we switch over, there's our email. So cool. Okay, but what about data for the view like we talked about? Okay, well, anything we define as a public property will automatically be available to the view. And basically, what's happening behind the scenes here, if you're, if you're curious, is that Laravel is going to use reflection to read all of the public properties on this class. And then that will populate your,

behind the scenes here, if you're, if you're curious, is that Laravel is going to use reflection to read all of the public properties on this class. And then that will populate your, your data array. And then that will be sent through to the view like usual. Because remember, the only difference between this Mailable class and the traditional way of saying Mail::send view data closure, the only difference is that a Mailable is just a wrapper around it, it just makes it a little more elegant for you to interact with. There's no separate thing going on here at all. In fact, if we take a look at this, let's look for Mail::send. Yeah. So you can see behind the scenes, it's doing the exact same thing that you normally would. But once again, we have a cleaner API to interact with. Oh, and real quick, if you want to see how we build the view data, this is what I mean. So it uses reflection. So it reflects into welcome to Lara class,

cleaner API to interact with. Oh, and real quick, if you want to see how we build the view data, this is what I mean. So it uses reflection. So it reflects into WelcomeToLara class, it finds all the public properties, and for each one, it builds up a data array. And that's what gets passed to the view. Kind of neat. So that means if I had something like this hard coded, then we could do this, WelcomeToLara class, and then the name of the property name. Okay, let's come back. We're going to give this a refresh, it'll fire it off. And now if we come back, WelcomeToLara cast Jeffrey. Or what you could even do is pass it through from your controller or your route. So we could say, $email = new WelcomeToLara cast, and then the $user, maybe. Let's say Jane this time. Alright, we have an $email, we're going to send the $email. So now WelcomeToLara can accept the $user and assign it here.

maybe. Let's say Jane this time. Alright, we have an email, we're going to send the email. So now welcome to Laravel cast can accept the User and assign it here. Like so. Now, your welcome view or your email has access to User, in which case you could say user name, something like that. Okay, let's try it one more time. Fire this off. Ah, sorry, we got to, we got to use it up here at user, and then from our routes file. Alright, one more time. Sorry about that. We fire it off. And now we pass the User into the mailable. And we fetched the name property off of it. And that's it. That's all there is to it. So like I said, if you want to do the old way, you still can, you don't have to change any of your code. But for me personally, yeah, I think this is so much cleaner. Mail to some address, and then send. And now the name of the class should reflect what it is you're sending. So maybe

your code. But for me personally, yeah, I think this is so much cleaner. Mail to some address, and then send. And now the name of the class should reflect what it is you're sending. So maybe you're sending a goodbye email when the User cancels. Okay, prepare it like this, pass through any data that the object might require. And now php artisan make:mail Goodbye. And you're all set to go. Pretty nice. This is easily one of my more favorite features in Laravel 5.3. It's great.