If you've been working with Laravel 5.0 and then install a fresh copy of 5.1, you might notice a couple folder changes. But don't worry, there are zero breaking changes here. First, you'll notice we no longer have a commands directory. In fact, you still have the same functionality, but it has been renamed to job. And, accordingly, if we run php artisan, you'll see if we scroll up, well yes, you still have make command, that'll eventually be deprecated, but you also have make job. php artisan make job. Calculate usage, I don't know, anything that's appropriate for your application. But you'll see that there, and it'll still look pretty much the same. It's only a name change meant to help encourage you to think of these things as queueable jobs, things you will likely want to tackle in the background.

It's only a name change meant to help encourage you to think of these things as queueable jobs, things you will likely want to tackle in the background. And with that in mind, if we were to run this again, we can add the queued flag here. Now if we take a look at it, and you'll now see that we implement the ShouldQueue interface. And what's cool about Laravel 5.0, and now subsequently 5.1, is that by simply implementing that interface, behind the scenes, Laravel will understand that you do intend to queue this job. And now, like before, within your handle method, you may type in any dependencies that you require, those will automatically be injected for you, and you can continue on your way. So mostly the same thing there. Next, on this same note, you'll see that we no longer have a handlers directory.

So mostly the same thing there. Next, on this same note, you'll see that we no longer have a handlers directory. Instead, well, just like the framework changed commands to jobs, it also changed handlers to listeners. And if you think about it, really, that makes more sense. Handler can sometimes be pretty generic, where you don't really know, okay, well, what exactly are we handling? So instead, the directory is called listeners. Here is where you listen for events that you can fire. Now remember, when you fire an event, we have a helper function here.

Here is where you listen for events that you can fire. Now remember, when you fire an event, we have a helper function here. You can either use a string, like you did in Laravel 4, User has registered, and then you'd pass that through. Or if you want this to be its own DTO, something like that, then you could say event new, and then the path to User has registered. But as for this part, none of this is new to Laravel 5.1. We are only recapping some 5.0 stuff. And then, of course, within EventServiceProvider, we could say, like our little example, when a User has registered, we want to fire, maybe send welcome email, or something like that.

And then, of course, within EventServiceProvider, we could say, like our little example, when a User has registered, we want to fire, maybe send welcome email, or something like that. Now, here's a cool thing you actually may not know about. If I run php artisan, and if I scroll up to the event section, you'll see that we have this command event:generate. Here's what that does. Typically, well, if you want to generate an event object, you have to say make:event. And then if you want a listener, you have to run make:listener. It's kind of time consuming. And then finally, you have to update your EventServiceProvider.

It's kind of time consuming. And then finally, you have to update your EventServiceProvider. So instead, what php artisan event:generate allows you to do, once again, not new to 5.1, this is 5.0. But anyways, what that allows you to do is you simply define it here. And then when you run php artisan event:generate, Laravel will read this and automatically trigger those commands for you. Let me show you. We run it. It read the file. So you now have a User has registered event.

It read the file. So you now have a User has registered event. And here you could pass through any properties that this event requires. Also take a look at that ShouldBroadcast interface. We'll talk more about that in a follow up lesson. But that's one of the great new features in Laravel 5.1. But anyways, we have that. And then we also have the listener. So why don't we just come down here and say var_dump caught the event. And then from something like routes.php, only for an example, we will fire the event.

So why don't we just come down here and say var_dump caught the event. And then from something like routes.php, only for an example, we will fire the event. new App\Events\UserHasRegistered. And like I said, in real life, you'd pass some data through to the constructor. But we don't really care about that right now. Okay, so let's just do anything to hit that routes file. And if I scroll up, sure enough, we fired the event and we caught it. Okay, so that does it. Mostly it's business as usual. Just keep in mind that commands is now jobs and handlers is now listeners.

Mostly it's business as usual. Just keep in mind that commands is now jobs and handlers is now listeners.