Як працюють Events та Listeners?

Події дають слабке зв'язування: одна частина застосунку «оголошує», що щось сталося, інші - реагують, нічого не знаючи одна про одну. event(new OrderShipped($order)); // диспатч // слухач class SendShipmentNotification { public function handle(OrderShipped $event): void { // ... } } Слухача, що реалізує ShouldQueue, обробляють асинхронно в черзі. У сучасному Laravel слухачі автоматично виявляються за type-hint у методі handle - ручна реєстрація не обов'язкова. Приклад: подія UserRegistered → слухачі «надіслати лист», «нарахувати бонус», «оновити статистику». Докладніше в документації: Events

Коли використовувати події, а коли викликати код напряму?

Подія повідомляє, що щось сталося, не знаючи, хто на це зреагує. Це розвʼязує звʼязок між тим, хто діє, і тим, хто відповідає. OrderPlaced::dispatch($order); Слухачі - лист, нарахування бонусів, повідомлення на склад - підписані окремо, і додати ще одного можна, не чіпаючи оформлення замовлення. Коли події доречні: На одну дію треба кілька незалежних реакцій, і їхній перелік з часом росте. Реакції належать іншим доменам - розсилка, аналітика, інтеграції. Реакція має піти у фонову роботу (ShouldQueue на слухачі). Реагувати мусить пакет чи модуль, який про ваш код не знає. Коли краще виклик напряму: Реакція єдина й завжди та сама. OrderPlaced з одним слухачем - це виклик методу, записаний у два файли. Порядок і результат важливі: подія не повертає значення й не гарантує послідовності. Дія - частина тієї самої операції, яка мусить відкотитися разом із нею. Головна пастка - невидимість. Через рік ніхто не скаже, що саме відбувається під час оформлення замовлення: у коді видно один рядок, а реально виконуються сім слухачів у різних файлах. Налагодження зводиться до пошуку по всьому проєкту. Друга пастка - транзакції. Подія, відправлена всередині DB::transaction(), може дійти до черги раніше, ніж транзакція завершиться, - і воркер не знайде запису. Для цього є ShouldDispatchAfterCommit на події або afterCommit на завданні. Правило: починайте з прямого виклику. Переходьте на подію, коли реакцій стало більше однієї або вони належать іншій частині системи. Докладніше в документації: Події

Middle: питання на співбесіді з теми «Events»

Найпопулярніші питання з реальних Laravel/PHP співбесід для всіх рівнів

Режим флеш-карток

Всі рівні Junior Middle Senior

Всі теми API Authentication Authorization Blade Broadcasting Caching Collections Database Debugging DevOps Eloquent Enums Events Filament Files HTTP та Request Livewire Mail Middleware MVC та архітектура Notifications Pagination Performance PHP Queues Routing Scheduling Search Seeder Service Container Service Providers Testing Архітектура Безпека Валідація Конфігурація Локалізація Міграції Сесії

2 питання

Події дають слабке зв'язування: одна частина застосунку «оголошує», що щось сталося, інші - реагують, нічого не знаючи одна про одну.

event(new OrderShipped($order)); // диспатч

// слухач
class SendShipmentNotification
{
    public function handle(OrderShipped $event): void
    {
        // ...
    }
}

Слухача, що реалізує ShouldQueue, обробляють асинхронно в черзі.
У сучасному Laravel слухачі автоматично виявляються за type-hint у методі handle - ручна реєстрація не обов'язкова.

Приклад: подія UserRegistered → слухачі «надіслати лист», «нарахувати бонус», «оновити статистику».

Докладніше в документації: Events

Подія повідомляє, що щось сталося, не знаючи, хто на це зреагує. Це розвʼязує звʼязок між тим, хто діє, і тим, хто відповідає.

OrderPlaced::dispatch($order);

Слухачі - лист, нарахування бонусів, повідомлення на склад - підписані окремо, і додати ще одного можна, не чіпаючи оформлення замовлення.

Коли події доречні:

На одну дію треба кілька незалежних реакцій, і їхній перелік з часом росте.
Реакції належать іншим доменам - розсилка, аналітика, інтеграції.
Реакція має піти у фонову роботу (ShouldQueue на слухачі).
Реагувати мусить пакет чи модуль, який про ваш код не знає.

Коли краще виклик напряму:

Реакція єдина й завжди та сама. OrderPlaced з одним слухачем - це виклик методу, записаний у два файли.
Порядок і результат важливі: подія не повертає значення й не гарантує послідовності.
Дія - частина тієї самої операції, яка мусить відкотитися разом із нею.

Головна пастка - невидимість. Через рік ніхто не скаже, що саме відбувається під час оформлення замовлення: у коді видно один рядок, а реально виконуються сім слухачів у різних файлах. Налагодження зводиться до пошуку по всьому проєкту.

Друга пастка - транзакції. Подія, відправлена всередині DB::transaction(), може дійти до черги раніше, ніж транзакція завершиться, - і воркер не знайде запису. Для цього є ShouldDispatchAfterCommit на події або afterCommit на завданні.

Правило: починайте з прямого виклику. Переходьте на подію, коли реакцій стало більше однієї або вони належать іншій частині системи.

Докладніше в документації: Події