Let's say I have some kind of event, maybe GiftCertificatePurchased. Now if I want to listen for this event in any number of ways, as you surely know, we can make a listener class. But I find sometimes, especially for smaller projects, this feels like overkill. It feels too complicated. So often what I like to do in those cases is, within my routes file, I register a new events.php file. I almost think of this as routing for my events, if that makes sense. It's a bit of a stretch, but it works. Next I can load it by visiting my events service provider, and maybe right down here we can

It's a bit of a stretch, but it works. Next I can load it by visiting my EventServiceProvider, and maybe right down here we can require it. Require in the base path, in the routes directory, events.php. So now, if I were to say, dd('hello world'), and if we view this in the browser, sure enough, we've executed that file. So now here, rather than creating a dedicated listener class, we can instead leverage event-based closures. For example, traditionally, in Laravel 7 and below, you would say, listen for the given event, so in this case, gift certificate purchased, and then handle it in some way.

For example, traditionally, in Laravel 7 and below, you would say, listen for the given event, so in this case, giftCertificatePurchased, and then handle it in some way. So the parameter here, though, would be the same thing again. So you end up with this number here, which is a little verbose. But sure enough, I could say, dd the event, or let's just say, handling it. Okay, so now let's trigger it on my routes file, or in my routes file. Let's just do it right up here. At some point, maybe when you submit a form, you handle some logic, and we will fire off this event that the giftCertificate has now been purchased. Now if I switch back, we listen for that event, and then respond to it by firing off an email,

this event that the gift certificate has now been purchased. Now if I switch back, we listen for that event, and then respond to it by firing off an email, storing something in the log, updating the database, whatever you want. So if I now come and give it a refresh, sure enough, we fired that event, we caught it, and then we responded in some way. Okay, so this will all work in Laravel 7 and below. But as of Laravel 8, this is simplified a bit. If you think about it, Laravel can read this parameter and figure out which event you're listening for, which means, if you like, you can remove this entirely, and that will work as well.

7, was that there was no easy way to queue your event listener. So unless your listener logic was super quick, maybe it didn't make as much sense, because it couldn't be queued. So for example, if you were doing some kind of lengthy database work or firing an email that wasn't automatically queued, you would have had to wait for all of that. But yeah, now, as of Laravel 8, there's actually a queueable function that we can import, like so. And I believe this is the first of its kind in Laravel, actually. Have a look. This function accepts the closure.

Have a look. This function accepts the closure. So the closure is this right here that handles the event. And all it does is it returns a queued closure that will ultimately resolve and dispatch it through a queue. So yeah, it might take a minute, but it's kind of an interesting solution there. And again, you would only reach for this if the logic within it was something time-consuming enough that it makes sense to throw it onto a queue. Otherwise, you can bring it back to what you had before, and you now have clean, closure-based event listeners.

Otherwise, you can bring it back to what you had before, and you now have clean, closure-based event listeners.