La situación es tal que utilizo la biblioteca axios y los interceptores de solicitudes exitosas y no exitosas para recoger y mostrar automáticamente una alerta con el texto de error del servidor en caso de error.
Entonces, mi desarrollador de back-end me envía mensajes de error que no son adecuados para generar una alerta argumentando que el mensaje es que tengo que generar el error yo mismo, pero lo que proviene del servidor solo es necesario para saber sobre el error. ¿Tiene razón, o enviar un mensaje de error desde el backend debería ser estrictamente como response.message y coincidir con el formato de error que se muestra al usuario en la interfaz de usuario?
El interceptor de errores universal del que hablé se ve así, pero los errores que me envía cada vez están en una ruta diferente, mientras que su formato no es adecuado para mostrar al usuario y, a menudo, una matriz con errores llega a la solicitud. . ¿Está haciendo lo correcto?
Porque en ese caso, no puedo usar el siguiente código para manejar los errores.
const API = axios.create({ baseURL: '/api/', responseType: 'json', headers: { 'cache': 'no-store' }, }) const onFulfilled = (response) => response.data const onRejected = (error) => { if (error.response?.status === 500) { notify(error.response.statusText || ' Internal server error', 'error') } else if (error.response?.data.message) { notify(error.response.data.message, 'error') } else { notify('Oops something went wrong', 'error') } ..... and so on return Promise.reject(error) } API.interceptors.response.use(onFulfilled, onRejected)Este es un dilema clásico, especialmente cuando los proyectos son jóvenes y todo sucede rápido. Hay una respuesta inmediata (¡y es correcta!), pero no es inmediatamente obvio lo que eso implica.
En general, el software de back-end informa al software de front-end, y el software de front-end informa a los usuarios humanos .
Lo que esto significa es que su back-end debe enviar información de error destinada a que un programa la analice, y su front-end debe interpretar y transformar eso en lenguaje e interfaz de usuario para las personas.
Esto es trabajo para ambas partes, sin embargo. Su servidor debería enviar suficiente información en forma fácilmente consumible. Dejame darte un ejemplo:
{ errorCode: ERROR_INVALID_SOMETHING, errorData: { something: 8, maxSomething: 5 } }El código front-end puede interpretar esto fácilmente y generar un mensaje adecuado para los usuarios humanos, como "¡Lo sentimos! Algo debe ser inferior a 5 y 8 es demasiado alto" . Terminarás con algo como esto:
switch (response.errorCode) { case ERROR_INVALID_SOMETHING: ... }Esto es muy difícil de lograr si el servidor envía cadenas no analizables sin estándares ni garantías de estabilidad. Un ejemplo atroz:
{ error: "InvalidSomethingException at server.x:15 maxSomething=5 but something is '8'" }El código front-end no puede funcionar con esto. Empeora si considera que la cadena puede cambiar por cualquier motivo, por ejemplo, si cambia el tipo de error.
Hay una familia de casos en los que mostrar cadenas del lado del servidor sin procesar al usuario no solo es aceptable, sino indispensable: cuando desea enviar mensajes personalizados para una situación particular a un software que no puede actualizar fácilmente.
Por ejemplo, de repente encuentra un error que pone en riesgo a los usuarios y necesita realizar un mantenimiento inmediato. Desea enviar un mensaje a sus usuarios lo antes posible y no puede esperar a que una tienda de aplicaciones apruebe una actualización dentro de los próximos 5 días hábiles.
Si su software estaba preparado para mostrar mensajes personalizados para tal eventualidad, este es un buen momento para hacerlo, pero los datos también deben seguir una buena estructura . Por ejemplo:
errorCode: ERROR_CUSTOM errorData: { en: "We need to inform you about something right now", es: "Necesitamos informarte de algo ya mismo" }Tenga en cuenta que esto sigue una estructura similar y que el código front-end aún puede funcionar con un estándar.
Debe sentarse con su equipo de back-end y llegar a un acuerdo compartido sobre cómo estructurar los errores y sus metadatos.
Esto puede requerir trabajo para comenzar, ya que necesita definiciones y posiblemente refactorizaciones, pero puede escalar a escenarios muy complejos y es posible que nunca necesite volver a trabajar en el código.
Los errores deben generarse a partir de escenarios, la API debe devolver el indicador correcto para representar el verdadero estado de extremo a extremo y dirigir/informar al usuario sobre lo que debe hacer a continuación o lo que sucedió en el sistema: las estructuras de mensajería genéricas deben evitarse en la API, excepto para 404 o 501, 500 falla. Cada mensaje lógico debe tener un valor instructivo para reducir la carga cognitiva.
Ejemplo: es posible que no se devuelva un artículo del carrito debido a una identificación de producto no válida, debido a una situación de falta de existencias, o puede faltar información requerida en el objeto. Todos estos escenarios deben devolver un indicador significativo para permitir que la interfaz se muestre informativa y clara mensaje al usuario sobre el estado del sistema final de una manera fácil de usar.
Los equipos de TI deben liderar este esfuerzo y ayudar a los socios comerciales a implementar la verborrea correcta de los mensajes. Esto sería impactante solo si existe una API adecuada para el diseño del marco de mensajería front-end que cubre escenarios funcionales y no funcionales.
En la mayoría de las aplicaciones, existe un verdadero back-end que realiza operaciones sobre los datos (recuperación, modificación, eliminación, adición). Ese verdadero back-end no tiene nada que ver con la presentación al usuario. Si tiene un error, simplemente debe informar ese error a la capa de presentación y luego depende de la capa de presentación saber cuál era el contexto del usuario y qué es y qué no es apropiado comunicar al usuario.
La capa de presentación puede estar completamente en el front-end o puede ser una combinación de representación de plantilla de back-end y visualización de front-end. En cualquier caso, el trabajo de la capa de presentación es mostrar los mensajes de error al usuario final en una forma que se ajuste al contexto y que tenga sentido para el usuario. A veces, esta presentación también incluirá un código de error (para usar en informes de errores más detallados y solución de problemas), pero ese código de error, por sí solo, generalmente no será útil para el usuario, excepto para informes más detallados de un problema.
Por lo tanto, no hay una respuesta precisa para el front-end o el back-end, ya que a veces el back-end está involucrado en la representación del contenido para que lo muestre el front-end. Cualquiera que sea la capa que presente información al usuario (dondequiera que esté) es lo que debería generar un mensaje de error para el usuario.
Si luego agrega soporte de idiomas donde tiene un front-end que se puede mostrar en muchos idiomas diferentes, puede ver de inmediato que no desea que sus API de back-end de administración de datos tengan que ser responsables de mostrar mensajes de error en un montón de idiomas diferentes. Esa es claramente la responsabilidad de una capa de presentación separada.