#¿Pero y el manejo de errores? Si por

1 messages · Page 1 of 1 (latest)

hollow magnet
#

Si es ese caso si, estaba asumiendo que siempre iba a encontrar un usuario autenticado.

Ojo: tienes un mensaje de error diciendo que ocurrio un error internet, podría ser más especifico diciendo que no existe un usuario autenticado.

#

y la pregunta del millon es, ¿ese caso existe? ¿el caso de que no encuentre un usuario autenticado?

supple cedar
#

Los trycatch si los estoy usando siempre para registrar cual quier error en un log ¿Lo ves buena práctica?

image.png
#

Es decir, usar los trycatch para el manejo de cualquier tipo de error

#

Porque podría crear una utilidad y simplemente llamar esa función

hollow magnet
#

Insisto, no trabajo con APIs,pero veo que tu estas manejando esos error, Laravel ya te hace todo ese trabajo y no deberías encargarte de eso.

#

Se asume que tienes un FormRequest que va maneja tus validaciones, si por cualquier motivo esa validación falla, laravel se encarga de responder eso con un json con los mensajes de errores listos.

supple cedar
#

a parte en la request ya lo tengo validado

image.png
hollow magnet
supple cedar
hollow magnet
#

Claro.

supple cedar
#

Es que no tenga nada de experiencia en producción y me siento muy inseguro de que no le retorne nada útil al usuario cuando suceda una falla y con el trycatch me asegurada de por lo menos registrarlo en un log. ¿Cuándo me recomendarías usar trycatch?

#

@hollow magnet

hollow magnet
hollow magnet
#

aunque siempre recomendare realizar testing a tus aplicaciones.

supple cedar
#

Nunca he hecho testing ni siquiera en front, supongo que esa es la principal razón y no es la primera vez que escucho algo así. @hollow magnet Agradezco tu tiempo, lo valoro mucho, lo voy a aplicar 🤝

minor garnet
#

Para lo del usuario, para eso le metes un middleware que compruebe que está autenticado

#

de hecho, así deberían de estar protegidas todas las rutas que requieran que hay un usuario autenticado

supple cedar
#

Para eso son las rutas protegidas

#

@minor garnet $request->validared() ¿toma todos los atributos que tengo en la request o como funciona?

minor garnet
#

regresa todos los campos que se validaron

supple cedar
minor garnet
#

cómo que datos de "usuario, credenciales" ?

#

si tienes un UpdateUserRequest, los campos que validas ahí son todos los datos que se van a actualizar del usuario

supple cedar
#

En mis bases de datos siempre pretendo normalizar las credenciales de los usuarios porque algunos usuario son datos del sistema

#

por ejemplo hay administradores y hay donadores de reciclaje

#

los donadores simplemente son datos del sistema

#

pero es solo un ejemplo para saber si hay alguna manera de separarlo como indicas o directamente como lo estoy haciendo

minor garnet
#

pues en caso que necesites separarlo, pues sí tendrías que meter un only()

#

pero sigo sin entender por qué tienes que separarlo ahí

supple cedar
minor garnet
#

lo único que se me ocurre es que estás queriendo actualizar diferentes cosas en una misma request

supple cedar
#

lo que hago es actualizar únicamente los datos del perfil ya que no siempre actualizan el correo o la contraseña

#

no voy a ponerle null al password 😅

minor garnet
#

para eso pones que el campo no sea requerido (? 🤷

supple cedar
minor garnet
#

haz la prueba imprimiendo lo que te regrese $request->validated()

#

hasta donde recuerdo, regresa los campos validados

#

si algo es opcional y no se envió, no sale ahí

#

por otro lado, dudo mucho que tu campo en la DB se llame currentPassword o newPassword, así que igual no es como que modificaría algo

#

tampoco creo que valides directamente currentPassword en el form request

supple cedar
minor garnet
supple cedar
minor garnet
#

y cómo tienes tu form request?

#

y qué enviaste?

supple cedar
#

Eso fue lo que envié

minor garnet
#

pues ahí estás enviando el password

supple cedar
minor garnet
#

no es lo mismo no enviarlo, a enviarlo vácio

supple cedar
#

ya pero, el address sí paso como null

minor garnet
supple cedar
#

🤔

#

¿donde identifica eso?

minor garnet
supple cedar
#

Ahhh las request, se llaman form request

minor garnet
#

la request es una cosa, los form request extienden request

#

para hacer la validaciones ahí

supple cedar
#

ciertoo, ahí dice form request

minor garnet
#

quita el nullable de los passwords y no los envíes

#

y $request->validated() no debería de regresarlos

#

bueno, el current supongo que siempre se debería de enviar, no?

#

o cómo lo estás haciendo?

supple cedar
#

No, el current es únicamente cuando van a cambiar la contraseña como autorización

#

Ahí le quité los nullables

#

cuando envío la solicitud desde el front, la api responde

image.png
minor garnet
#

pero entonces el current le deberías de poner que es requerida si existe newPassword

minor garnet
#

bueno, también current está ahí doge

supple cedar
#

¿Te refieres a que la quite del fetching?

image.png
minor garnet
#

sí, solo envía los datos que se vayan a actualizar

#

como dije, validated() regresa los campos que se validaron (y se enviaron)

#

si a las passwords le pones que pueden ser null, y las envías

#

pues eso, las validó y las regresa

supple cedar
#

Yo siempre envío todos los datos y me imagino que la query del update solo actualizará los que son diferentes

minor garnet
#

sí, eso hace

supple cedar
#

Me tocaría realizar la lógica para que cada formulario envíe solo los atributos que actualizaron

minor garnet
#

y por cierto, para sacar ciertos datos de los validados es con $request->safe()->only(...);

minor garnet
#

así que, en teoría, no debería de afectar en nada que se incluyan

#

y el $fillable debería de hacer que se excluyeran de la query

supple cedar
minor garnet
#

y podría hacer que si el newPassword es diferente de null, agregarlo en los campos

#

pero pues yo diría que los passwords no deberían de ser nullable, pero sí opcionales

#

y pues eso, si no los vas a actualizar, pues no los envías 🤷

supple cedar
minor garnet
#

también podrías separar lo de actualizar los datos de usuarios y cambiar contraseña en diferentes request

supple cedar
minor garnet
minor garnet
#

para que se incluya en el update

supple cedar
#

simplemente actualiza la clave si ya está en la request

image.png
minor garnet
supple cedar
minor garnet
#

pero pues eso, current_password supondría que prácticamente no te sirve de nada si le pones que pueda ser nullable

#

bueno, sí, pero pues también pasaría si tiene null

supple cedar
#

Estoy haciendo lo de la request no sé como puedo puedo obtener cierto campos, mira:

minor garnet
#

qué estás intentando hacer ahí?

supple cedar
#

Lo que intento es construir el arreglo con las validaciones que requiero validar

#

pero no sé como obtener atributos especificos

minor garnet
#

y por cierto, eso más que $validated sería $rules

supple cedar
# 
public function rules(Request $request): array
  {
    $rules = [
      "name"            => 'required|string|min:3|max:50',
      "lastname"        => 'required|string|min:3|max:50',
      "address"         => 'nullable|string|min:3|max:100',
      "phone"           => 'nullable|string|min:10|max:15',
      "birthdate"       => 'nullable|date',
      "email"           => 'required|email|max:100',
    ];

    if ($request['newPassword'] !== null) {
      $rules[] = [
        "currentPassword" => 'required|current_password',
        "newPassword"     => ['required', 'confirmed', Password::defaults()],
      ];
    }

    return $rules;
  }
minor garnet
# supple cedar

y por cierto, así como lo tienes, $validated tendría una estructura como:

[
    [
        'currentPassword' => 'required|current_password',
        'newPassword' => ['required', 'confirmed', Password::defaults()],
    ],
    [
        'name' => /* ... */,
        'lastname' => /* ... */,
        // ...
    ],
]
supple cedar
#

fatal

minor garnet
supple cedar
# 
public function rules(Request $request): array
{
    $rules = [
        "name"       => 'required|string|min:3|max:50',
        "lastname"   => 'required|string|min:3|max:50',
        "address"    => 'nullable|string|min:3|max:100',
        "phone"      => 'nullable|string|min:10|max:15',
        "birthdate"  => 'nullable|date',
        "email"      => 'required|email|max:100',
    ];

    if ($request['newPassword'] !== null) {
        $rules += [
            "currentPassword" => 'required|current_password',
            "newPassword"     => ['required', 'confirmed', Password::defaults()],
        ];
    }

    return $rules;
}
minor garnet
#

y por cierto, no creo que rules() reciba un request

supple cedar
minor garnet
#

mejor ve a buscar a la doc

#

eso es lo que deberías de haber hecho desde el inicio thisisfine

#

solo te voy a decir, que ahí mismo estás en un Request

supple cedar
#

Vale, sí, lo hice por intentar algo, dame un par de minutos

minor garnet
#

por cierto, lo que yo te decía era algo diferente babyyoda

#

ya que ahí sigues sin agregar password a los campos

supple cedar
#

Mira ¿debería hacer el condicional así?

image.png
#

Vale lo tengo, es un objeto:

public function rules(): array
{
  $rules = [
    "name"       => 'required|string|min:3|max:50',
    "lastname"   => 'required|string|min:3|max:50',
    "address"    => 'nullable|string|min:3|max:100',
    "phone"      => 'nullable|string|min:10|max:15',
    "birthdate"  => 'nullable|date',
    "email"      => 'required|email|max:100',
  ];

  if ($this->newPassword !== null) {
    $rules += [
      "currentPassword" => 'required|current_password',
      "newPassword"     => ['required', 'confirmed', Password::defaults()],
    ];
  }

  return $rules;
}
minor garnet
supple cedar
#

Aunque podría crear una función que reciba los valores iniciales y los nuevos para extraer solo los diferentes 🤔

minor garnet
#

si tiene algo, lo incluyes junto con currentPassword

#

si no, no

#

de hecho, hasta ahí mismo podrías enviar password en lugar de newPassword

#

y ya no tendrías que andar modificando nada en el back

supple cedar
minor garnet
#

si estás actualizando, password se entiende que es el password babyyoda

#

y si estás enviando currentPassword, se entiende que ese es el actual 🤷‍♂️

#

aunque sí, entiendo que con newPassword podría ser más específico en que esa es la nueva. Pero pues eso, tendrás que poner algo para agregar password a los campos

supple cedar
#

No, tienes razón.

#

Finalmente lo deje como antes

image.png
#

sin los nullables

#

¿Hasta ahí lo ves bien?

#

Estoy aprendiendo un montón, de verdad te agradezco el tiempo

minor garnet
#

ahí lo único que diría es que currentPassword sea requerido si existe password

#

si mal no recuerdo, hay una condición para eso

#

creo que es required_with

supple cedar
# minor garnet creo que es `required_with`

Efectivamente, ya mire las demás alternativas pero ese es el apropiado, hice la lógica para que en front solo envíe los campos que fueron alterados y le añadí también el required_with

image.png
#

Pero olvidé percatarme que esas reglas también la quería usar para el store

#

entonces por ejemplo no puedo quitarle el required a los campos requeridos

minor garnet
#

crea otro form request doge

supple cedar
minor garnet
#

pues es más limpio que tengas tu requests separados

#

de hecho, si mal no recuerdo, si al crear un modelo le pones que te cree los request, te crea 2

#

uno para store y otro para update

supple cedar
#

Pero los nombres funcionarían para ambos casos

image.png
supple cedar
#

Sólo me funciona con este

image.png
minor garnet
#

sí, la única vez que lo he usado desde ahí, si mal no recuerdo, fue con all

#

supondría que, quizás, un -r 🤷

supple cedar
minor garnet
#

entonces ni idea

#

revisa la ayuda a ver qué dice 🤷

#

pero pues igual también puedes crear los request individualmente

supple cedar
#

definitivamente seguiré tu sugerencia, gracias @minor garnet

supple cedar
#

@minor garnet una última duda por favor. solo me queda el asunto del controlador, voy a aprender testing más adelante pero por ahora no sé si es necesario usar un trycatch o tal vez sobra?

image.png
supple cedar
#

Me has dado un respiro increíble

image.png
minor garnet
#

y el try para qué era? 🤔

supple cedar
minor garnet
#

para eso ya hay un handler (no recuerdo dónde)

#

App\Exceptions\Handler

supple cedar
#

Te refieres a esto?:

<?php

namespace App\Exceptions;

use Illuminate\Foundation\Exceptions\Handler as ExceptionHandler;
use Throwable;

class Handler extends ExceptionHandler
{
    /**
     * The list of the inputs that are never flashed to the session on validation exceptions.
     *
     * @var array<int, string>
     */
    protected $dontFlash = [
        'current_password',
        'password',
        'password_confirmation',
    ];

    /**
     * Register the exception handling callbacks for the application.
     */
    public function register(): void
    {
        $this->reportable(function (Throwable $e) {
            //
        });
    }
}
minor garnet
#

por lo que vi, sí

#

y pues, si mal no recuerdo, Laravel ya te regresa un mensaje de error si ocurre algo

#

eso es solo por si quieres presonalizar alguno

#

o interceptarlo

supple cedar
#

@minor garnet Estoy provocando el problema intencionalmente el error de unique en el email. ¿Cómo puedo devolver simplemente un mensaje personalizado? quiero aprovechar también para hacerle Log

image.png
#

Intenté esto, pero no:

image.png
minor garnet
#

ni idea, hace tiempo que no me meto con eso

#

y por cierto, te regresa todo eso porque estás en debug