Closed jcsoriano closed 8 months ago
Elimination of the EventServiceProvider
Namespace 🚫
This part of the code, a sort of digital meeting room where many of the tools our code uses to handle events, was taken out. No need to worry, this doesn't mean our toolbox is short of any tools, it just means we're reorganizing a bit!
Introduction of New Characters to the Story 🎭 We've welcomed some new players into our magical code realm. This includes:
MessageSent
class (fresh from the Illuminate\Mail\Events
namespace) - it's all about dealing with email messages after they've been sent.Event
class from Illuminate\Support\Facades
- this one helps our code to marshall events in a better way.ServiceProvider
from Illuminate\Support
- it's a real generalist! It makes sure that the right tools for the job are in the right place at the right time.Casting a New Lead Role 🎬
Instead of the usual EventServiceProvider
, we now have ServiceProvider
taking the spotlight in the class declaration. It's not a scandal or coup, just a little switcheroo that will make our process more streamlined and efficient! 😉
Thanks for quick fix!
Resolves https://github.com/RickDBCN/filament-email/issues/37
Some notes:
EmailMessageServiceProvider
extending from Laravel'sEventServiceProvider
messes up event registrationMessageSent
event, and they only extend fromIlluminate\Support\ServiceProvider
EventServiceProvider@listen
get registered again, and the listener of the package gets registered automatically via autodiscovery againEventServiceProvider
just to useEvent::listen
, since you could technically useEvent::listen
from any service provider, so extending fromServiceProvider
should be alright and is probably more correct. It seems extending fromIlluminate\Events\EventServiceProvider
is what broke listener registration on our end