Symfony 5. Novedades de esta nueva versión
Descubre las novedades que traerá la nueva versión de Symfony
English version: https://medium.com/@ger86/symfony-5-whats-new-in-this-new-version-3e2385c2d0b7
Bueno pues ya tenemos la versión 5 de Symfony entre nosotros por lo que creo que es un buen momento para hacer un repaso de todas las novedades que trae. En este artículo no profundizaré sobre ninguna de ellas sino que haré un repaso de cada una de ellas de cara a que podáis tener una visión general de las nuevas características con las que contaremos a partir de ahora. En las próximas semanas prepararé artículos independientes para cada una de las nuevas funcionalidades y componentes más destacados.
Así que sin entretenernos más… ¡vamos a ello!
Pero antes… ¿qué diferencia hay entre Symfony 5 y Symfony 4.4?
Seguramente esta es una de las preguntas que aquellos que no estéis muy familiarizados con los ciclos de desarrollo de Symfony os estaréis haciendo, ya que ambas han sido liberadas a la vez.
Las diferencias son dos principalmente:
- Por un lado, Symfony 4.4 pasa a ser la versión LTS (long term support) reemplazando de este modo a la antigua versión 3.4
- Por el otro, Symfony 5 es prácticamente igual que Symfony 4.4 salvo que no cuenta con el código que ha sido marcado como deprecado en la versión 4.4. De este modo, si desarrolláis un proyecto desde cero podréis empezarlo con Symfony 5 pero para proyectos ya existentes lo recomendado es actualizar a la versión 4.4, eliminar todo el código deprecado y de ahí saltar a la versión 5 cuando sea necesario.
Esta forma de plantear las actualizaciones permite al equipo de Symfony proseguir el desarrollo de nuevas características por medio de la versión 5 a la vez que ofrece una compatibilidad “hacia atrás” en el largo plazo mientras los proyectos se actualizan a dicha versión. Este es uno de los puntos que más me gustan de Symfony y la verdad es que es de agradecer que cuiden tanto este aspecto. Un aplauso por ellos. 👏👏👏
Dicho esto, y tomando como referencia el artículo “Living on the edge” de la documentación oficial de Symfony, vamos a ver las principales novedades.
Encriptar y firmar emails
Con el desarrollo del componente Mailer del cual ya hablamos en un pasado artículo:
el equipo de Symfony está trabajando en ampliar su funcionalidad y gracias a ello, a partir de ahora podremos firmar y encriptar los emails. Para ello, podremos recurrir a los componentes Symfony\Component\Mime\Crypto\SMimeSigner y Symfony\Component\Mime\Crypto\SMimeEncrypter .
Por ejemplo, si queremos firmar un email de cara a asegurar su integridad podremos realizar lo siguiente:
use Symfony\Component\Mime\Crypto\SMimeSigner;
use Symfony\Component\Mime\Email;$email = (new Email())->from('...')->to('...')->html('...');$signer = new SMimeSigner('/path/to/certificate.crt', '/path/to/certificate-private-key.key');$signedEmail = $signer->sign($email);$gmailTransport = new GmailTransport('user', 'password');
$gmailTransport->send($signedEmail);
Leer más: https://symfony.com/blog/new-in-symfony-4-4-signing-and-encrypting-email-messages
PHPUnit y Componente Mailer
Otra de las ventajas de las que podremos disfrutar ahora que poseemos el componente Mailer es poder realizar aserciones sobre lo que ha sucedido en lo que respecta al envío de emails dentro de un servicio o controlador.
Por ejemplo, dispondremos del método assertEmailCount para validar el número de emails enviados o acceder a un email concreto mediante el método getMailerMessage(index) de cara a realizar aserciones sobre:
- La dirección a la que se ha enviado mediante:
$this->assertEmailHeaderSame($email, 'To', 'to@mail.com') - El contenido del cuerpo del email mediante
$this->assertEmailTextBodyContains($email, 'Text to check') - O el número de adjuntos mediante
$this->assertEmailAttachementCount($email, $count)
Una gran mejora que nos permitirá añadir nuevos tests a nuestro código.
Leer más: https://symfony.com/blog/new-in-symfony-4-4-phpunit-assertions-for-email-messages
Emails de notificación
Sí, estaréis pensando lo mismo que yo: Muchas de las novedades de esta versión están centradas en los emails lo cual nos transmite las ganas que tenía el equipo de Symfony de mejorar esa “pata” del proyecto.
Ahora con la versión 5 de Symfony podremos enviar emails de notificación con un aspecto similar al siguiente:
con tan sólo emplear la clase:
Symfony\Bridge\Twig\Mime\NotificationEmail;Mejora en la validación de tipos
A partir de ahora podremos especificar varios tipos a la hora de validar una propiedad empleando la constraint Type . De este modo podemos validar si el valor dado a una propiedad es de uno de los tipos especificados:
namespace App\Entity;
use Symfony\Component\Validator\Constraints as Assert;
class Address
{
// ...
/**
* @Assert\Type(type={"alpha", "digit"})
*/
protected $postalCode;
}De este modo, la propiedad postalCode podrá ser o bien numérica o bien contener sólo letras. Es decir, PC2800 no sería válido.
Leer más: https://symfony.com/blog/new-in-symfony-4-4-improved-type-constraint
Añadida la constraint AutoMapping
Como sabréis, con la llegada de Symfony 4.3 es posible realizar validaciones del modelo sin necesidad de especificar las aserciones correspondientes:
Sin embargo, y dado que esto se configura a nivel de proyecto, a veces es necesario desactivar esta validación automática en determinadas clases o propiedades, para lo cual se ha añadido la constraint AutoMapping que podremos situar a nivel de clase o propiedad de cara a activar o desactivar esta característica.
Los Event Listener son aún más fáciles de declarar
Con el fin de conseguir que los Event Listeners sean igual de sencillos de declarar que los Event Subscribers, desde la versión 4.4 Symfony inspeccionará el tipo de argumento pasado al método __invoke de nuestro Event Listener de modo que ya no sea necesario especificar el tipo de evento que estamos escuchando en la configuración dentro del archivo services.yaml .
Es decir, si tenemos lo siguiente:
namespace App\EventListener;
use Symfony\Component\HttpKernel\Event\RequestEvent;
final class MyRequestListener
{
public function __invoke(RequestEvent $event): void
{
// ...
}
}Symfony sabrá que el Event Listener declarado está asociado al evento Kernel::REQUEST ya que el evento es del tipo RequestEvent .
Por lo que nuestro archivo services.yaml cambiará de:
# config/services.yaml
services:
App\EventListener\MyRequestListener:
tags:
- { name: kernel.event_listener, event: kernel.request }a lo siguiente:
# config/services.yaml
services:
App\EventListener\MyRequestListener:
tags:
- { name: kernel.event_listener }Leer más: https://symfony.com/blog/new-in-symfony-4-4-simpler-event-listeners
WeekType
Esta es una de esas pequeñas mejoras que siempre se agradecen cuando llega el momento de usarlas. Con la llegada de Symfony 4.4 tenemos a nuestra disposición el tipo WeekType para nuestros formularios. Este nuevo tipo nos permitirá modificar el valor de un campo que represente el número de semana en formato ISO 8601.
Además, WeekType nos da multitud de opciones a la hora de definir tanto el tipo del dato como el widget que lo representa. Por ejemplo, si guardamos dicho dato en formato array (año, semana) y queremos mostrar dos selects podremos emplear WeekType del siguiente modo:
use Symfony\Component\Form\Extension\Core\Type\WeekType;
$builder->add('startDateTime', WeekType::class, [
'input' => 'array',
'widget' => 'choice',
]);Leer más: https://symfony.com/blog/new-in-symfony-4-4-week-form-type
Mejoras en el componente HttpClient
Otro de los componentes que han sufrido una gran mejora ha sido el componente HttpClient el cual por si no lo conocíais es una alternativa a la librería Guzzle para enviar peticiones HTTP.
Con la llegada de Symfony 4.4 se nos ha añadido funcionalidad como:
- Debuggear la respuesta mediante el método
$response->getInfo('debug')de cara a obtener los logs relacionados con la petición. - Cancelar peticiones en cualquier momento gracias al método
cancel(). - Convertir respuestas a streams de PHP empleando la clase
Symfony\Component\HttpClient\Response\StreamWrapper.
Aunque en cada pull request se van añadiendo nuevas características. Podéis revisar todas las novedades en el siguiente enlace: https://symfony.com/blog/new-in-symfony-4-4-httpclient-improvements
Service Container Linter
Este es otro de los añadidos que si estamos trabajando con metodologías como integración continua agradeceremos muchísimo. Esta nueva característica nos provee del comando lint:container el cual comprobará que los argumentos de los servicios inyectados en el container sean los correctos.
Por ejemplo, si tenemos el siguiente servicio:
namespace App\Service;
class SomeService
{
public function __construct(string $foo = 'foo')
{
// ...
}
}y el siguiente archivo services.yaml :
services:
App\Service\SomeService: ~el comando lint:container nos devolverá el siguiente fallo:
Invalid definition for service "App\Service\SomeService": argument 1 of
"App\Service\SomeService::__construct" accepts "string", "NULL" passed.Muy muy útil, por lo que la propia documentación recomienda integrar este comando en nuestro proceso de integración continua antes de cada despliegue.
Leer más: https://symfony.com/blog/new-in-symfony-4-4-service-container-linter
Integración con PHP 7.4
Con el fin de aprovechar la característica preload de PHP 7.4 se ha añadido un archivo *.preload.php en la carpeta cache . Recordad que esta característica permite listar todos aquellos archivos que queramos que sean precargados en memoria de modo que se pueda mejorar significativamente el rendimiento del código.
Mejoras en el comando lint:twig
Además del comando lint:container disponemos del comando lint:twig en el caso de que queramos revisar nuestros archivos Twig. Sin embargo, hasta Symfony 4.3 era necesario especificar la ruta donde se encontraban los archivos que queríamos comprobar. Con Symfony 4.4 por defecto se revisarán todos los archivos especificados en la configuración de Twig ( twig paths ).
Conclusiones
Como veis, Symfony 5 no trae grandes novedades como en cambio supuso el año pasado la llegada de Symfony 4. Sin embargo, sí que se aprecia una estabilidad en el proyecto lo cual se traduce en:
- La mejora de componentes que ya se encuentran en versión estable con una base de código unificada sobre la que trabajar.
- El refinamiento de la funcionalidad ya existente introduciendo mejoras que poco a poco incrementan la robustez del sistema.
Estos dos puntos creo que son la mejor expresión de la madurez que está adquiriendo el ecosistema de Symfony y la explicación de que muchas empresas lo estén escogiendo para llevar a cabo sus desarrollos.
¿Quieres recibir más artículos como este?
Si te ha gustado este artículo te animo a que te suscribas a la newsletter que envío cada domingo con publicaciones similares a esta y más contenido recomendado: 👇👇👇
