Mengatasi Penundaan Notifikasi Pada Laravel
Mengirim pemberitahuan di aplikasi Laravel Anda tidak pernah semudah ini, berkat fungsionalitas Pemberitahuan bawaan. Notifikasi dapat dikirim melalui hampir semua saluran yang dapat Anda pikirkan — dalam aplikasi, email, SMS, push, telepon, aplikasi obrolan, dll — dapat diantrekan, dapat dibuat templat, dan sangat mudah digunakan.
Banyak pemberitahuan dikirim pada saat itu: ketika suatu tindakan terjadi, ketika suatu keadaan berubah, atau ketika beberapa peristiwa lain dipicu, dan ketika Anda mengetahui kondisi pasti apakah pemberitahuan harus dikirim atau tidak. Namun bagaimana bila Anda perlu mengirimkan notifikasi di luar momen tersebut, seperti 5 menit atau 2 jam atau 3 hari sebelum atau sesudah suatu tindakan atau peristiwa? Dan, yang lebih penting, bagaimana jika situasinya dapat berubah antara tindakan dan waktu yang Anda perlukan untuk mengirim pemberitahuan?
Dengan menggunakan kombinasi metode delay() dan via(), plus event, Anda dapat menangani notifikasi bersyarat dengan elegan.
Pengaturan
Katakanlah kita memiliki pemberitahuan yang harus dikirim 24 jam sebelum janji temu. Pemberitahuan mungkin terlihat seperti ini:
<?php
namespace App\Notifications;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Notifications\Notification;
use Illuminate\Queue\SerializesModels;
class AppointmentReminder extends Notification implements ShouldQueue
{
use Queueable, SerializesModels;
public $appointment;
public function __construct(Appointment $appointment)
{
$this->appointment = $appointment;
$this->delay($appointment->start_date_time)->subDay(1);
}
public function via($notifiable)
{
return ['mail'];
}
public function toMail()
{
// Return mail contents
}
} Metode delay() memungkinkan kita untuk mengantrikan notifikasi tetapi menunda pengirimannya hingga kapan pun kita mau, notifikasi dapat segera dikirim. Terlepas dari kapan pengguna memesan janji temu, pemberitahuan dapat dijadwalkan untuk tidak dikirim hingga, katakanlah, tepat satu hari sebelum janji temu.
$user->notify(new AppointmentReminder($appointment));Pemeriksaan Kewarasan
Metode via() dipanggil pada saat notifikasi akan diantrekan untuk menentukan saluran yang akan digunakan untuk notifikasi. Metode ini dapat menggunakan logika bisnis kita sendiri untuk menjadi pintar dan memeriksa apakah notifikasi harus diantrekan sama sekali. Dalam contoh ini, kami mengenkapsulasi logika tersebut dalam metode publik sekunder dontSend(). Ini penting.
Ayo perbarui notifikasi kita.
<?php
namespace App\Notifications;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Notifications\Notification;
use Illuminate\Queue\SerializesModels;
class AppointmentReminder extends Notification implements ShouldQueue
{
use Queueable, SerializesModels;
public $appointment;
public function __construct(Appointment $appointment)
{
$this->appointment = $appointment;
$this->delay($appointment->start_date_time)->subDay(1);
}
public function via($notifiable)
{
if($this->dontSend($notifiable)) {
return [];
}
return ['mail'];
}
public function dontSend($notifiable)
{
return $this->appointment->status === 'cancelled';
}
public function toMail()
{
// Return mail contents
}
}Jika pemeriksaan gagal maka via() mengembalikan larik saluran notifikasi yang kosong dan tidak ada yang dikirim.
Oke, sejauh ini baik-baik saja. Jika janji temu telah dibatalkan pada saat kami mengantri pemberitahuan maka itu tidak akan dikirim. Ini baik-baik saja, tetapi tidak berguna seperti yang seharusnya. Sepertinya janji temu tidak akan dibatalkan sesaat setelah dipesan.
Apa yang terjadi jika pengguna memesan janji temu beberapa minggu sebelumnya, tetapi sejak itu dibatalkan? Pemberitahuan sehari sebelum seharusnya tidak dikirim, tetapi kami tidak dapat dengan mudah mengeluarkannya dari antrean. Di sinilah Acara masuk.
Barang
Setiap kali pemberitahuan sedang ditangani di Laravel, acara NotificationSending pertama kali dipancarkan. Kami dapat menggunakan acara ini untuk sekali lagi memeriksa apakah notifikasi harus dikirim, berkat SerializesModels dan metode DontSend kami.
Lihat kumpulan kelas berikut:
<?php
namespace App\Base\Providers;
use App\Notifications\Listeners\NotificationSendingListener;
use Illuminate\Foundation\Support\Providers\EventServiceProvider as ServiceProvider;
use Illuminate\Notifications\Events\NotificationSending;
class EventServiceProvider extends ServiceProvider
{
protected $listen = [
NotificationSending::class => [
NotificationSendingListener::class,
],
];
public function boot()
{
parent::boot();
}
}<?php
namespace App\Notifications\Listeners;
use Illuminate\Notifications\Events\NotificationSending;
class NotificationSendingListener
{
public function handle(NotificationSending $event)
{
if (method_exists($event->notification, 'dontSend')) {
return !$event->notification->dontSend($event->notifiable);
}
return true;
}
} Dengan mendengarkan acara itu dan kemudian memeriksa metode dontSend() kami pada notifikasi kami, kami dapat melakukan pemeriksaan saat itu juga saat notifikasi sedang ditangani untuk melihat apakah itu masih valid. Anda bahkan dapat mengakses objek $notifiable, yang memungkinkan Anda memeriksa data baru tentang pengguna atau entitas yang Anda beri tahu.
Seperti yang Anda lihat, menangani notifikasi antrian bersyarat bisa sangat mudah! Beri tahu pengguna Anda kapan pun Anda mau, dan yakinlah bahwa notifikasi Anda tidak akan pernah terkirim saat mereka tidak lagi berlaku.