Service providers: cargar componentes sin instanciar

Domina los conceptos clave del núcleo de Laravel con un enfoque práctico y claro. Aquí verás cómo los service providers cargan clases esenciales, cómo se integran con el service container y cómo usar un view composer para compartir datos con vistas sin instanciar manualmente componentes.

¿Qué son los service providers y cómo operan en Laravel?

Los service providers viven en la carpeta providers y son la puerta de entrada para cargar servicios y clases esenciales. Ya has trabajado con AppServiceProvider, donde se registran los gates de políticas y que extiende de la clase base ServiceProvider.

• Están compuestos por dos métodos: register y boot.
• register: registra clases o servicios en el container. No ejecuta lógica que dependa de servicios ya registrados.
• boot: se ejecuta después de registrar todos los service providers. Ideal para inicializar comportamientos que dependen de otros servicios.
• Secuencia de carga: se levanta la aplicación, se registran todos los service providers y luego se llama a boot de cada uno.
• Beneficio clave: inicializar una clase o componente sin instanciarlo de antemano.
• Conexión con el núcleo: el flujo de la petición se comunica con los service providers y estos operan respaldados por el service container.

¿Cómo crear y registrar un provider con php artisan?

Para extender funcionalidades de Laravel o integrar un paquete de terceros, puedes generar un provider con el comando de consola. El archivo se crea dentro de providers.

php artisan make:provider RatingProvider

Regístralo en el arreglo providers del archivo de configuración:

// config/app.php
'providers' => [
    // ...
    App\Providers\RatingProvider::class,
];

Puntos clave que desarrollas como habilidad práctica:

• Uso de php artisan make:provider para scaffolding del provider.
• Registro manual en config/app para habilitarlo en la aplicación.
• Comprensión de los métodos register y boot y cuándo usar cada uno.

¿Cómo compartir datos con un view composer desde boot?

Un caso útil: compartir datos con una vista específica mediante un view composer definido en boot. Primero, puedes verificar la ejecución con un dd(true) y luego reemplazarlo por la lógica real.

Ejemplo dentro de tu provider:

use Illuminate\Support\Facades\View;
// ...
public function boot(): void
{
    View::composer('home', function ($view) {
        // Prueba inicial.
        // dd(true);

        // Compartir datos reales con la vista 'home'.
        $view->with('rating', RatingResource::collection(Rating::all()));
    });
}

Detalles y conceptos que aplicas:

• helper view y método composer para enlazar lógica a una vista en particular.
• Variable compartida: rating.
• Fuente de datos: Rating Resource con collection sobre all para enviar todos los registros como recurso.

En la vista home, itera la colección con foreach para mostrar los datos necesarios, como rateable->name y score:

<ul>
@foreach($rating as $r)
    <li>{{ $r->rateable->name }} — {{ $r->score }}</li>
@endforeach
</ul>

Con este patrón, consigues:

• Inyección automática de datos en vistas sin duplicar lógica.
• Separación limpia entre obtención de datos y renderizado.
• Flujo alineado al ciclo de vida: el composer corre tras el registro de servicios, dentro de boot.

¿Tienes dudas, casos de uso o quieres compartir cómo integraste service providers y view composers en tu proyecto? Deja tus comentarios y continuemos la conversación.