<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Qawelesizwe Mlilo</title>
    <description>The latest articles on DEV Community by Qawelesizwe Mlilo (@qawemlilo).</description>
    <link>https://dev.to/qawemlilo</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F63187%2F68ac8442-2ded-4002-8095-ba2be59a80f3.jpeg</url>
      <title>DEV Community: Qawelesizwe Mlilo</title>
      <link>https://dev.to/qawemlilo</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/qawemlilo"/>
    <language>en</language>
    <item>
      <title>Auto-registering events and listeners in Laravel 5.8</title>
      <dc:creator>Qawelesizwe Mlilo</dc:creator>
      <pubDate>Mon, 30 Sep 2019 13:01:14 +0000</pubDate>
      <link>https://dev.to/qawemlilo/auto-registering-events-and-listeners-in-laravel-5-8-kkd</link>
      <guid>https://dev.to/qawemlilo/auto-registering-events-and-listeners-in-laravel-5-8-kkd</guid>
      <description>&lt;p&gt;For the past 4 years I have been working on a &lt;code&gt;Laravel 4.2&lt;/code&gt; application which I inherited as an MVP. This application has grown over the years and accumulated a lot of technical debt. About a month ago I started refactoring the entire codebase and upgrading it to &lt;code&gt;Laravel 5.8&lt;/code&gt;. This process has presented a number challenges which have required a pragmatic approach.&lt;/p&gt;

&lt;p&gt;In this post I will share with you how to auto-register events and listeners which is useful when handling a large number of events and listeners. &lt;/p&gt;

&lt;p&gt;Our application has more than 100 different emails that are triggered by different types of events. In our old set up, all the events were defined in one file and the logic lived in a 'god' Mailer class which was about 4000 lines long. In the upgrade I decided to follow the observer implementation with each event, listener, and mailer having its own class. This approach would help with decoupling and maintenance of the application's mailing logic. Below is an illustration of directory structure in the upgrade:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight"&gt;&lt;pre class="highlight plaintext"&gt;&lt;code&gt;App/
  Events/
    UserRegistered.php
  Listeners/
    HandleUserRegistered.php
  Mail/
    UserRegistered.php
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;



&lt;h3&gt;
  
  
  Registering Events &amp;amp; Listeners
&lt;/h3&gt;

&lt;p&gt;Breaking down our Mailer class led to the creation of 100s of files for events, listeners and mailers. When events and listeners have been created, they need to mapped and registered in the &lt;code&gt;EventServiceProvider&lt;/code&gt;. Manually importing all events and listeners in &lt;code&gt;EventServiceProvider&lt;/code&gt; quickly became messy as the class got too large making it easy to introduce errors and mix up the pairing of events and listeners.&lt;/p&gt;

&lt;p&gt;This problem got me wondering, is there a better way of registering events and listeners without explicitly importing them in the &lt;code&gt;EventServiceProvider&lt;/code&gt;? I did a bit of googling but no satisfactory results came up. So I decided to write my own solution.&lt;/p&gt;

&lt;h3&gt;
  
  
  The Idea
&lt;/h3&gt;

&lt;p&gt;Create a method in the &lt;code&gt;EventServiceProvider&lt;/code&gt; that does the following:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Searches for all event classes&lt;/li&gt;
&lt;li&gt;Finds their corresponding listeners&lt;/li&gt;
&lt;li&gt;Pairs and registers them&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;In order for this idea to work I needed to come up with a predictable naming convention for the events and listeners. This is how I did it: for every event class created, I create a corresponding listener which adds &lt;code&gt;Handle&lt;/code&gt; as a prefix to the event class name. For example, if I have an event called &lt;code&gt;UserRegistered&lt;/code&gt;, the corresponding listener class would be named &lt;code&gt;HandleUserRegistered&lt;/code&gt;.&lt;/p&gt;

&lt;h3&gt;
  
  
  The solution
&lt;/h3&gt;

&lt;p&gt;Below is the new implementation of the &lt;code&gt;EventServiceProvider&lt;/code&gt;.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight"&gt;&lt;pre class="highlight plaintext"&gt;&lt;code&gt;&amp;lt;?php

namespace App\Providers;

use Illuminate\Support\Facades\Event;
use Illuminate\Foundation\Support\Providers\EventServiceProvider as ServiceProvider;


class EventServiceProvider extends ServiceProvider
{
  protected $listen = [];


  public function boot()
  {
      parent::boot();

      $this-&amp;gt;registerEventsAndListeners();
  }


  protected function registerEventsAndListeners()
  {
    $eventsDir = app_path('Events');

    foreach (glob("$eventsDir/*.php") as $filename) {
      $eventClassName = basename($filename, ".php");

      Event::listen('App\Events\\' . $eventClassName, 'App\Listeners\Handle' . $eventClassName);
    }
  }
}
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;



&lt;p&gt;Now I have a clean and minimal &lt;code&gt;EventServiceProvider&lt;/code&gt; plus I don't have to worry about registering events and listeners that I create in future. &lt;/p&gt;

&lt;p&gt;Let me know what you think. Do you have any interesting solutions for this problem?&lt;/p&gt;

</description>
      <category>php</category>
      <category>laravel</category>
      <category>events</category>
      <category>listeners</category>
    </item>
  </channel>
</rss>
