…
Seguir leyendoContinuando con los form requests revisaremos que opciones nos dan para validar datos.
Índice
Form requests
Primero vemos que Laravel creó dos para nosotros: StoreCreditCardRequest y
UpdateCreditCardRequest, este par de form requests servirán para validar los
datos, dar autorización en la capa de solicitudes, enviar mensajes entendibles
como respuesta y en algunas ocasiones podemos realizar pre-procesamientos en la
validación.
Almacenar
Autorización
El método authorize devuelve verdadero si el usuario puede tener acceso a
esta solicitud. Lo hemos implementado así:
public function authorize(): bool
{
return $this->user()->can('create', CreditCard::class);
}
Reglas
Después está el método rules que devuelve el arreglo de reglas que tienen que
cumplir los campos, nosotros queremos que al solicitar el almacenamiento de una
tarjeta, tenga en cuenta el nombre, fecha límite de pago, fecha de corte, tasa
de interés y límite de crédito.
El único campo opcional o nullable es la tasa de interés, a los demás les agregamos otras reglas, como que son requeridos:
Nombre
- Requerido
- Cadena de texto
- Máximo 255 caracteres
Fecha límite de pago
- Requerido
- Entero
- La fecha límite de pago representa un día en el mes corriente, en el que debes terminar de pagar tu deuda, o sea que no tiene sentido que sean negativos y seguramente no habrá días mayores a 28 porque pues ✨ febrero ✨
Fecha de corte
- Requerido
- Entero
- Similar a la fecha de corte, en el sentido que la acotaremos de 1 a 28
Tasa de interés
- No requerido
- Decimal, puede tener de 0 a 2 decimales
- Este porcentaje debería ser mayor a 0 y menor a 200, ya que si tu tarjeta tiene más de 200% como tasa de interés… bueno quizá después tengamos que cambiar esto
Límite de crédito
- Requerido, para poder saber cuanto tienes disponible en cualquier momento
- Decimal, puede tener de 0 a 4 decimales
- Debe ser mayor a 0 (espero que no tengas un límite de crédito negativo 😬)
Laravel utilizara estas reglas para validar los datos que lleguen desde la API.
Atributos
Luego tenemos el método attributes, que devolverá un arreglo que indica a
Laravel cómo sustituir los nombres de los atributos, para que se vean bonitos,
básicamente. Ahí sustituimos el atributo name por Nombre (y así con los
demás), y lo traducimos, para que si el usuario utiliza otro de nuestros
lenguajes soportados y nos lo indica así, podamos responder de forma clara.
En resumen el código para la solicitud de almacenamiento de una tarjeta de crédito queda así… (Ya teníamos algunas reglas escritas)
Actualizar
Haremos lo mismo para la solicitud de actualización de la tarjeta, con algunas excepciones.
Para la autorización, necesitamos tomar en cuenta la tarjeta de crédito que se está solicitando actualizar.
Y en las reglas habrá campos que el usuario no quiera actualizar, por lo que marcaremos algunos campos como sometimes para decirle a Laravel que esos campos no estarán presentes en todas las solicitudes de actualización, pero también los marcamos como required ya que no pueden ser null.
Y por último agregamos también los atributos.
Fixes
Ahora bien, en nuestro PR anterior nos faltaban algunas cosas, cómo decirle al
controlador, que nombre debía tener el parámetro tarjeta de crédito, ya que el
método authorizeResource lo obtiene automáticamente con snake case, pero
nosotros estamos usando camel case.
Al final, el código queda algo así:
Pruebas con Postman
Probaremos el endpoint POST credit-cards en Postman, para lo que agregamos la
url y hacemos una solicitud con valores de prueba.
Vemos que los mensajes están “localizados”, es decir traducidos a una variante específica de un idioma, en este caso el español de México.
Si hacemos una solicitud vacía podremos ver algo así:
Y por último si enviamos los datos correctos se verá algo así…
Esto es porque todavía no contamos con la lógica en el controlador.
Conclusión
Podemos ver que las form requests son bastante ágiles para realizar tareas de validación, además que abstrae muchas cosas que de otra forma tendríamos que escribir por nosotros mismos (como la autorización y los mensajes).
Esto es todo lo que haremos en este sprint (ya que no me quedó mucho tiempo libre) y en el siguiente veremos cómo interactuar con el ORM Doctrine, para guardar los datos que recuperamos de la solicitud.