Is it possible to pass data to the customized Mailer/Transport from the notification/channel?

[ngdangtu-vn]

My question invokes these 2 doc pages:

• https://laravel.com/docs/9.x/mail#custom-transports
• https://laravel.com/docs/9.x/notifications#customizing-the-mailer

My goal is to create a custom mailer that can run using API from the request/db instead load it from config file. The only way I found from the doc is passing the data during register the transport in service provider (I use AppServiceProvider as doc recommend). However, the data from service provider doesn't come in as expected (depends on the entry HTTP or Console). While the data, that are more stable, can used during creating notification/channel.

[mazesec]

Creating a custom mailer in Laravel that dynamically pulls configuration from an API or database instead of relying on static configuration files is a bit intricate but definitely achievable. Let's break down the steps you can take to implement this.

Step 1: Create the Custom Transport

You’ll need to create a custom transport class that will handle sending the email using the data fetched from your API or database.

namespace App\Mail\Transport;

use Swift_Transport;
use Swift_Mime_SimpleMessage;

class CustomTransport implements Swift_Transport
{
    public function isStarted()
    {
        // Implementation
    }

    public function start()
    {
        // Implementation
    }

    public function stop()
    {
        // Implementation
    }

    public function send(Swift_Mime_SimpleMessage $message, &$failedRecipients = null)
    {
        // Fetch your dynamic configuration here (from API or database)
        $config = $this->getDynamicConfig();

        // Use the config to send the email (e.g., using a third-party API)
        // ...

        return $result; // Return the result of the send operation
    }

    protected function getDynamicConfig()
    {
        // Fetch configuration from your database or API
        // This can be a synchronous or asynchronous call depending on your setup
    }
}

Step 2: Register the Transport in the Service Provider

Next, you’ll need to register this transport in your AppServiceProvider. You can pass data or even inject dependencies as necessary.

namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use Illuminate\Mail\TransportManager;
use App\Mail\Transport\CustomTransport;

class AppServiceProvider extends ServiceProvider
{
    public function boot()
    {
        // Custom transport registration
        $this->app['mail.manager']->extend('custom', function ($app) {
            return new CustomTransport();
        });
    }

    public function register()
    {
        //
    }
}

Step 3: Using the Custom Mailer

You can then use your custom mailer in your notifications or wherever you need to send an email. When you define your notification, specify the mail channel as follows:

use Illuminate\Notifications\Notification;

class MyNotification extends Notification
{
    public function via($notifiable)
    {
        return ['mail']; // This will utilize your custom mailer
    }

    public function toMail($notifiable)
    {
        return (new MailMessage)
            ->subject('Subject Here')
            ->line('Your message body here.');
    }
}

Step 4: Customize the Mailer Logic

Since you need to customize the mailer depending on whether the request is HTTP or console, you might want to check the context within your transport or where you're constructing the notification. You can modify how you fetch configurations based on the environment:

protected function getDynamicConfig()
{
    if (app()->runningInConsole()) {
        // Fetch console-specific configuration
    } else {
        // Fetch HTTP-specific configuration
    }
}

Additional Considerations

1. Error Handling: Ensure that you handle any errors when fetching the configuration or sending the email gracefully.

2. Performance: If your API calls are slow, consider caching the results or implementing asynchronous calls where feasible.

3. Testing: Test both HTTP and console scenarios to ensure your dynamic configurations work as expected in both contexts.

With these steps, you should be able to create a custom mailer that adapts based on dynamic configurations pulled from your database or an API, effectively making it versatile for different environments.

[ngdangtu-vn]

Thanks @tal7aouy for your support. I'm fairly amateur in Laravel, so there is lots of thing I don't get it well. Hope you don't mind to tell me about one thing:

$this->app['mail.manager']->extend('custom', function ($app) {

Does the dot in 'mail.manager' have any special meaning or it is a literal string? From you code, it seems that this is syntax to create a nesting mailer and if something calls its top then every name behind the dot will be called. If so does it have limit of nesting level?

use Swift_Transport;

The doc recommend me AbstractTransport, does your solution work with this transport?