Now, like we did with scheduling in episode 2, in this video, let's take a peek behind the curtains and figure out how event dispatching in Laravel works. Alright, so let's take a look at this test code that we wrote in the previous episode. We fire an event which announces to our entire application, anyone who wants to listen for it, that a User was banned. So if we take a look at our helper function, if you remember, I told you in the last episode that this is just a little helper function that basically delegates to event fire. Let's take a look. If we open that up, yeah, we can see we grab the events key out of the container. We'll review that in just a minute.

If we open that up, yeah, we can see we grab the events key out of the container. We'll review that in just a minute. And then we call the fire method on it. We pass through the event. Now that could be a string or that could be an object. And that's because in Laravel, you can do either. So for example, you could also say event User was banned, and then you pass that through as a string. Or you can new up an object. It's up to you.

Or you can new up an object. It's up to you. And then you can pass through your payload right here. Any data that you want sent through to the event. Okay, so we fire it. We pass through the event. We pass through a payload. And then you can also pass through halt, which would be a Boolean. And that just means when you set it to true, well, you know what, I'll just show you really quickly.

And that just means when you set it to true, well, you know what, I'll just show you really quickly. So let's go over to dispatcher and let me hunt down halt. There it is. We're going to go over this code quite a bit more, but just to give you a quick hint, if a response is returned from the listener and event halting is enabled, meaning you pass through, we will just return the response and not call the rest of the event listeners. Okay. So you probably don't use that very much, but it's cool to know it is an option if you want it.

So you probably don't use that very much, but it's cool to know it is an option if you want it. All right. So now though, what about this app events? How does that reflect the actual event dispatcher? And this is where service providers come into play. So if we were to take a look at the EventServiceProvider, and there would actually be two, right? There would be your own local copy of the EventServiceProvider. And then there would be Laravel's specific EventServiceProvider, which would be right

There would be your own local copy of the EventServiceProvider. And then there would be Laravel's specific EventServiceProvider, which would be right here. Now, if you want to access this manually, you'd go to vendor, laravel, framework, src, Illuminate, Events. And here is the events component, so to speak, into our service provider. This is what bootstraps the component into the Laravel application. Okay. So let's take a look at this. Well, we set up a singleton.

It's not like every time you say app events, it's going to new up a Dispatcher class. And if we take a look, let's see here. Well, we new up the EventDispatcher class. We pass through the Laravel container, just represented by app. And then we just have a quick setter here to pass through the queue resolver. Don't worry about that too much. The main thing to recognize is that we are returning a new EventDispatcher. So that means we're going to, if we open this up, this is what gets returned when you do something like this, app events. You get this object right here.

something like this, app events. You get this object right here. So now we got this part set up. What about when we call fire? Well, there should be a fire method on this, and there is. Cool. Now, before we dig into this, we should figure out how we listen for events. We're kind of jumping ahead right now. We're figuring out how firing an event works before we even understand how to listen for an event.

We're figuring out how firing an event works before we even understand how to listen for an event. Okay, well, if we go back to our routes file, don't forget that you can do manual things like this, listen for when a User was banned, and then I'm either going to trigger a class or I can pass a closure here. This is very common in Laravel 4, and you can still do it in Laravel 5, but, well, if we go back to our own EventServiceProvider that we reviewed in the last episode, we also have this nice clean syntax that we can use where behind the scenes, Laravel basically automates that process of writing event listen for each one. I'll show you.

automates that process of writing event listen for each one. I'll show you. Here you can see we are extending this class, and if we take a look at it, and if I scroll down, there we go, within the boot method. All right, so you can see we filter through everything in the listen property. If we switch back, we're just filtering through that. So we're going to say for each one as the event we're listening for, and then an array of handlers, so let's see, for each listener as the event we're listening for, as an array of listeners, well, then we'll filter through that array of listeners, and for each one, we're just going to call events listen.

of listeners, well, then we'll filter through that array of listeners, and for each one, we're just going to call events listen. We pass through that name. So in this case, it would be userWasBanned, listen for when a user was banned, and trigger that class, or resolve it out of a container, and then trigger it. So yeah, we can see that this right here is just a little bit of sugar that does the exact same thing that you've always been doing, and you may not know it, but you can also do this if we scroll down. It does something similar for a subscribe property, and if we scroll up, you can see it right here.

It does something similar for a subscribe property, and if we scroll up, you can see it right here. So if you prefer the process of using a dedicated class to register your event subscriptions, then you could do the exact same thing right here, protected subscribe, and then you could set it here. You may not have known that. Okay, cool. So now we recognize how we are calling event listen, but we still don't exactly know what happens when you trigger that listen method. Well, we know that happens on the dispatcher, right?

happens when you trigger that listen method. Well, we know that happens on the dispatcher, right? So if we look for a listen method, there it is. Now in our case, we're just passing through a string. Laravel converts it to an array just because you can do either or, and this makes it a little more consistent. So we check to see, is the event you're listening for, does it contain a star? And if so, that means you're trying to listen for any kind of event. So for example, if you have a system like user.registered, user.canceled, well, if you listen for user.*, you're basically saying, I want to listen for when anything under this

So for example, if you have a system like user.registered, user.canceled, well, if you listen for user.star, you're basically saying, I want to listen for when anything under this namespace, so to speak, is fired. In our case, that doesn't apply. So let's keep it simple and come down here. Okay, so we're updating a listeners array. We pass through the event, which is user was banned. So why don't we just replace that to make it easier? And then if you want greater priority, you can pass that through. You may not have known that either, but we'll keep the default.

And then if you want greater priority, you can pass that through. You may not have known that either, but we'll keep the default. And then within that priority for this event, we're going to add a new key and we will construct the listener. And really, that's about it for this method. When you call event listener, you're really just sort of updating an array. It's just a glorified way of managing that. And by the way, if you're curious what makeListener does, while we pass it our listener, remember, this is sort of like if you do event listen, User was banned, well, you could pass a class that would be resolved, or you could pass a closure to handle it directly there.

this is sort of like if you do event listen, User was banned, well, you could pass a class that would be resolved, or you could pass a closure to handle it directly there. So Laravel just sort of normalizes that. If we take a look, okay, if you pass a string, then that is something that references a class that we want to resolve. Otherwise, we can just return the closure there. And that is what will be called when we trigger event fire. Okay, cool. So back in routes.php, we know the basics, the essentials of how you listen for an event. Now we're ready to fire the event.

So back in routes.php, we know the basics, the essentials of how you listen for an event. Now we're ready to fire the event. So that means we head back to the dispatcher and we take a look at fire. Now let's take a look at the comments. Laravel has really good commenting. When the given event is actually an object. So what it's checking for here is when you say event new User was banned, well, don't forget you can do that, or like we talked about, you could pass through a string. Either of those are acceptable. So we're saying on the condition that you pass through an object, well, we'll assume

Either of those are acceptable. So we're saying on the condition that you pass through an object, well, we'll assume that it's an event object and we will use the name of the class as the name of the event. So take a look. If we have an object, then we'll set payload equal to, well, just the object itself because the event object, don't forget, contains everything you need here. Okay, so that will be the payload. And then we will set the name of the event equal to whatever the class name of the event. So in this case, it would be the class path to UserWasBanned. Cool.

So in this case, it would be the class path to User was banned. Cool. Not that hard. So let's continue on. Next, we do a quick little check here, and that's because you could say event fire User was banned, and then you could just pass through something like this if you want to. That would work, or that would work. And the reason is because of this section right here. If what you pass through as that second argument is not an array, then we're just going to turn it into an array for you.

If what you pass through as that second argument is not an array, then we're just going to turn it into an array for you. Okay, next we designate that we are firing the event. So we just update an array. This is what we are currently firing. And then we look into the payload. And this specific section right here is what handles the should broadcast aspect that we talked about in the previous episode. If your event class implements, like we talked about, implements should broadcast, then that means we want to broadcast it to our client side.

If your event class implements, like we talked about, implements shouldBroadcast, then that means we want to broadcast it to our client side. So here's where we check for that. We look in the payload. Remember at this point, it would be something like that, or user was banned. It'll be an array containing our event object. And we're going to look into that and say, is this object, is it an instance of shouldBroadcast? Well, we take a look. Yes, it is.

Well, we take a look. Yes, it is. So in that case, we want to make sure that we broadcast the event. That's how Laravel handles that. Okay, but otherwise, or continuing on, we're going to fetch all of our listeners. So every time, remember, that we would call the equivalent of event listen, we updated that array, right? So now we're going to fetch that. And for each one of them, there we go, we call the listener function. So don't forget, listener is either a closure.

And for each one of them, there we go, we call the listener function. So don't forget, listener is either a closure. So you could have said User was banned, and then you have your function right here. Okay. So we're just calling this function. And then we're passing through the payload, which will be sent through as an array to populate anything that you require here. Then from this point on, it's just some additional checks. For example, we already discussed that possibility of passing halt. So if we pass halt, then we'll just return immediately and not trigger any of the other.

For example, we already discussed that possibility of passing halt. So if we pass halt, then we'll just return immediately and not trigger any of the other event listeners. Next, if our event handler returns false, well, that means we don't want to propagate and continue triggering any other event listeners. So we will just end immediately. But yeah, then mostly we're at the end of the method. That's the essentials of it. Of course, there's more intricacy going on here. And I do encourage you to dig through this code on your own.