El caso de las grandes declaraciones de middleware

El objetivo del middleware es lo simple que es declararlo. La mayoría de las veces está a una cuerda de distancia, pero es posible que tenga un paquete que inevitablemente le exija establecer un gran conjunto de parámetros.

Por ejemplo, este paquete Captchavel contiene un middleware que, según la aplicación, puede requerir entre tres y cuatro parámetros.

Este último PR  busca simplificar esto usando una pequeña idea: ¿qué hay de declarar un objeto Stringable? Una vez que los objetos entran en el método de middleware, se transforma en una cadena y walá. Bueno, eso ahora es posible.

Podemos usar un setter fluido que traducirá un montón de cadenas de qué-hace-qué en algo con menor carga cognitiva para comprender.

Los beneficios directos no están en el marco, ya que el único middleware que requiere más de un parámetro es el  throttle, y ese se usa raramente.

Más bien, la gran cantidad de paquetes que deben lidiar con middleware se beneficiarán de esto. Al usar un objeto  Stringable podemos:

1. Evite usar el middleware por el nombre de la clase si no tiene un alias, y
2. establezca los parámetros en cualquier orden.

Si bien la declaración se hace más grande en unos pocos caracteres, la intención es más clara, lo que es una gran victoria en términos de mantenibilidad.

Detrás de escena, cualquier objeto de clase que implemente la interfaz Stringable hará el trabajo pesado con el método  __toString() . Por ejemplo, este es un ejemplo simplificado de cómo funciona el asistente de clase  ReCaptcha:

Hay una gran cantidad de ventajas en el uso de objetos que se pueden representar como cadenas. Para resumir:

• Carga cognitiva más baja para comprender qué valor hace qué.
• Ya no es obligatorio registrar un alias en el kernel HTTP.
• Ya no es necesario enviar nombres de clases de middleware y concatenar parámetros manualmente.
• Puede establecer valores en cualquier orden.
• Puede establecer valores predeterminados en el asistente en lugar del propio middleware.

La única advertencia de declarar middlewares es la naturaleza de los parámetros. Todos los parámetros que se pasan al middleware se convertirán en cadenas. Tendrá que convertirlos en su tipo apropiado dentro de su middleware, como en el caso de números enteros, decimales y listas.

Dado que todos los parámetros son cadenas, el último miembro de la cadena  foo, se transformará en una cadena vacía, no  null, por lo que es posible que deba actuar en consecuencia en su middleware.

En general, es una buena adición al marco. Podría haber sido más simple si pudiéramos haber usado tipos de unión para el argumento, transformar la cadena en una matriz y convertir en una cadena cada miembro, pero eso habría sido catastrófico, ya que habría roto la aplicación para cualquier persona por debajo de PHP 8.

Espero que esta pequeña característica ayude cuando se trata de middleware que rápidamente se convierte en un garabato de una línea.