Custom Events in Laravel

In this article, we are going to explore the basics of event management in Laravel. It’s one of the important features that you, as a developer, should have in your arsenal in your desired framework. As we move on, we’ll also grab this opportunity to create a real-world example of a custom event and listener, and that’s the ultimate goal of this article as well.

The concept of events in Laravel is based on a very popular software design pattern—the observer pattern. In this pattern, the system is supposed to raise events when something happens, and you could define listeners that listen to these events and react accordingly. It’s a really useful feature in a way that allows you to decouple components in a system that otherwise would have resulted in tightly coupled code.

For example, say you want to notify all modules in a system when someone logs into your site. Thus, it allows them to react to this login event, whether it’s about sending an email or in-app notification or for that matter anything that wants to react to this login event.

Basics of Events and Listeners

In this section, we’ll explore Laravel’s way of implementing events and listeners in the core framework. If you’re familiar with the architecture of Laravel, you probably know that Laravel implements the concept of a service provider that allows you to inject different services into an application.

Similarly, Laravel provides a built-in EventServiceProvider.php class that allows us to define event listener mappings for an application.

Go ahead and pull in the app/Providers/EventServiceProvider.php file.

Let’s have a close look at the $listen property, which allows you to define an array of events and associated listeners. The array keys correspond to events in a system, and their values correspond to listeners that will be triggered when the corresponding event is raised in a system.

I prefer to go through a real-world example to demonstrate it further. As you probably know, Laravel provides a built-in authentication system that facilitates features like login, register, and the like.

Assume that you want to send the email notification, as a security measure, when someone logs into the application. If Laravel didn’t support the event listener feature, you might have ended up editing the core class or some other way to plug in your code that sends an email.

In fact, you’re on the luckier side as Laravel helps you to solve this problem using the event listener. Let’s revise the app/Providers/EventServiceProvider.php file to look like the following.

IlluminateAuthEventsLogin is an event that’ll be raised by the Auth plugin when someone logs into an application. We’ve bound that event to the AppListenersSendEmailNotification listener, so it’ll be triggered on the login event.

Of course, you need to define the AppListenersSendEmailNotification listener class in the first place. As always, Laravel allows you to create a template code of a listener using the artisan command.

This command generates event and listener classes listed under the $listen property.

In our case, the IlluminateAuthEventsLogin event already exists, so it only creates the AppListenersSendEmailNotification listener class. In fact, it would have created the IlluminateAuthEventsLogin event class too if it didn’t exist in the first place.

Let’s have a look at the listener class created at app/Listeners/SendEmailNotification.php.

Powered by WPeMatico

Leave a Comment

Scroll to Top