Nuevo en Symfony 4.3: Eventos más sencillos

En Symfony 3.3, simplificamos la configuración de servicios recomendando que sus IDs fueran la FQCN de la clase asociada al servicio. Además de hacer que el código fuera más sencillo de entender, esto evitaba tener que pensar cadenas de texto arbitrarias para identificar los servicios.

Aplicando la misma idea, en Symfony 4.3 hemos cambiado el método EventDispatcherInterface::dispatch() de la siguiente manera:

// ...
$order = new Order();
$newOrderEvent = new OrderPlacedEvent($order);
 
// Antes
$dispatcher->dispatch(OrderEvents::NEW_ORDER, $newOrderEvent);
 
// Después
$dispatcher->dispatch($newOrderEvent, OrderEvents::NEW_ORDER);

Aunque a primera vista puede parecer un cabio irrelevante, permitirá simplificar el uso de los eventos. En primer lugar, ahora puedes suscribirte a los eventos usando directamente su clase, en vez de una cadena de texto arbitraria con el nombre del evento:

class StoreSubscriber implements EventSubscriberInterface
{
    public static function getSubscribedEvents()
    {
        // Antes
        return [
            OrderEvents::NEW_ORDER => 'onStoreOrder',
        ];
 
        // Después
        return [
            OrderPlacedEvent::class => 'onStoreOrder',
        ];
    }
 
    // ...
}

Además, como el nombre del evento ahora es opcional en el método dispatch(), puedes pasar simplemente el objeto del evento y olvidarte de definir nombres para los eventos:

// Antes
$dispatcher->dispatch(OrderEvents::NEW_ORDER, $newOrderEvent);
 
// Después
$dispatcher->dispatch($newOrderEvent);

En resumen, el nuevo método dispatch() permite diseñar tu código solamente con clases PHP, sin tener que inventarte cadenas de texto arbitrarias para nombrar a los eventos.

Actualizados loe eventos de HttpKernel

Aprovechando el cambio anterior, también hemos actualizado las clases que pasa Symfony a cada uno de los eventos internos del propio framework. Los nombres de las nuevas clases son mucho más concisos y fáciles de entender:

• FilterControllerArgumentsEvent ahora se llama ControllerArgumentsEvent
• FilterControllerEvent ahora se llama ControllerEvent
• FilterResponseEvent ahora se llama ResponseEvent
• GetResponseEvent ahora se llama RequestEvent
• GetResponseForControllerResultEvent ahora se llama ViewEvent
• GetResponseForExceptionEvent ahora se llama ExceptionEvent
• PostResponseEvent ahora se llama TerminateEvent

Cómo soportar las dos formas de trabajar con eventos

Los bundles y aplicaciones que quieran dar soporte a las dos formas de trabajar con los eventos, pueden usar la clase LegacyEventDispatcherProxy de la siguiente manera:

use Symfony\Component\EventDispatcher\EventDispatcherInterface;
use Symfony\Component\EventDispatcher\LegacyEventDispatcherProxy;
 
class SomeService
{
    public function __construct(EventDispatcherInterface $dispatcher)
    {
        $this->dispatcher = LegacyEventDispatcherProxy::decorate($dispatcher);
    }
 
    public function someMethod()
    {
        // ...
 
        // en este método, utiliza solamente la nueva forma de trabajar con eventos (con o
        // sin el nombre del evento) y la clase LegacyEventDispatcherProxy hará los cambios
        // necesarios internamente para que funcione en cualquier versión de Symfony
        $this->dispatcher->dispatch($newOrderEvent);
        $this->dispatcher->dispatch($newOrderEvent, OrderEvents::NEW_ORDER);
    }
}

Esta funcionalidad fue contribuida por Nicolas Grekas en el pull request #28920.

Fuente: New in Symfony 4.3: Simpler event dispatching

• © 2024 - symfony.es
• Contacto
• Privacidad
• Condiciones
• v7