¿Cómo maneja el front-end las excepciones ajax de la forma más correcta posible?
En pocas palabras, en los negocios, cualquier código que no sea 200 es una excepción. Aquí, el código puede ser un código de estado HTTP o un código de cuerpo de respuesta, por lo que no entraré en detalles. De todos modos, esencialmente no hay diferencia. Luego, dependiendo del código, se puede subdividir en 401 403 404 500 y así sucesivamente.
Si sus socios de backend indican 404 con el código de estado HTTP y otros errores con el código del cuerpo de la respuesta, y no puede convencerlos, entonces debe considerar varios casos en los interceptores de axios, por ejemplo:
Los tiempos de espera son simples y están respaldados por axios. Simplemente establezca el umbral de tiempo de espera. La diferencia entre tiempo de espera y no respuesta es que el tiempo de espera significa que el protocolo de enlace HTTP de tres vías fue exitoso, pero no se puede obtener el cuerpo de la respuesta. El navegador sabe que la interfaz existe, pero no puede obtener el cuerpo de la respuesta dentro del tiempo especificado. Sin respuesta significa que no puede estrechar la mano del HTTP en absoluto, por lo que no tiene forma de saber que la interfaz existe.
Para manejar los tiempos de espera, la práctica común es solicitar el tiempo de espera nuevamente en un interceptor; de lo contrario, se tratará como un error del servidor si se produce un tiempo de espera.
La falta de respuesta se puede dividir en dos tipos, que pueden ser una interrupción de la red o un tiempo de inactividad del servidor.
Estrictamente hablando, debes distinguir entre estas dos situaciones y dar indicaciones diferentes. Después de todo, cuando la red está desconectada, los usuarios pueden encontrar otras formas de conectarse a Internet, y cuando el servidor no funciona, se proporciona un botón de reconexión para que los usuarios intenten volver a conectarse.
En cuanto a la solución, en primer lugar, el objeto XHR no puede determinar si la red está desconectada o el servidor está apagado. axios devuelve "Error de red" en ambos casos. Después de recibir estos comentarios, puede tener estas dos soluciones:
Puede cambiar /images/blank.gif en otros servidores a imágenes estables de bytes pequeños. Tal vez podrías crear una imagen de unos pocos bytes y subirla a una CDN realmente interesante.
Manual MDN: https://developer.Mozilla.org/zh-cn/docs/web/API/navigator/connection.
No es compatible con IE. Incluso si esto no te importa, ¿seguramente es exacto? ¿Es preciso para redes VPN que requieren inicio de sesión? No tengo ni idea. En general, esta no es realmente la mejor solución. Recomiendo la opción 1.
Muy simple, dividido en tres tipos:
Por lo general, una interfaz solo necesita procesarse de acuerdo con uno de ellos, y la prioridad es el orden de escritura anterior.
El mensaje de error en el contenedor debe ser un error de interfaz en el área de contenido.
Método de procesamiento:
Es más fácil comprender los errores locales. Por ejemplo, si la interfaz de una lista tiene un error, la mejor estrategia es soportar el contenedor lo más alto posible cuando hay contenido y luego dar el icono de error y la descripción del error en el centro. La estrategia intermedia es no considerar la altura cuando hay contenido y solo dejar que los mensajes de error y las descripciones de error admitan una cierta altura. Ninguno de ellos está equivocado. Si el contenedor es pequeño, como un valor de 3 dígitos, entonces - se puede utilizar para indicar un error.
Los informes de errores en toda la página son un poco más complejos, como un sistema de gestión de contenidos con una estructura de izquierda a derecha. La interfaz de usuario incluye una interfaz de información de usuario, una interfaz de diccionario global, una interfaz de enrutamiento global, etc. La diferencia entre estas interfaces es que son interfaces básicas. Si cometen un error, el sitio queda inutilizable y los marcos de las páginas quedan desordenados. En este caso, hay dos soluciones: una es saltar a una página especial de informe de error 5xx con un ícono de error y un mensaje de error en el centro de la página, y la otra es ". El segundo método es cubrir el navegador con una ventana de pizarra y coloque un ícono de error, un texto de error y un botón de "actualizar página" en el centro. Básicamente, use una máscara fija que contenga toda el área del navegador. Entonces, lo que debe hacer es decidir cuál. interfaces pertenecen al informe de fallas global y qué interfaces pertenecen al informe de fallas local, y manejarlas de manera diferente.
Contenido del error:
Según la clasificación de excepciones ajax, puede haber al menos tres tipos: errores de red, tiempo de inactividad del servidor y errores del servidor. No entraré en detalles sobre los íconos y el texto específicos.
Componentización:
Los informes de errores en contenedores deben ser lo más modulares posible. Si es hora de presionar el botón Volver a la página anterior o Actualizar, asegúrese de presionar ese botón.
Exclusividad:
Una vez que te equivoques con un contenedor, no lo vuelvas a cometer. Esto también muestra que jugar brindis o modal en axios interceptor es una estupidez, he mencionado este punto en otros artículos. Los otros tres casos sólo deben considerarse si no se informan errores en el contenedor.
¿Qué tipo de escenarios se ocultan mediante contenedores?
Por ejemplo, hay una esquina en la página que muestra tus fans, seguidores y comentarios. Si se obtienen los datos, aparecerá el contenedor, en caso contrario, el contenedor permanecerá oculto. Este escenario generalmente se aplica a contenido no principal, como pequeños bloques de contenido en la barra lateral.
Dado que esto solo se aplica al contenido no principal, el contenido principal también tendrá sus propios errores, por lo que no tienes que preocuparte de que los usuarios no vean mensajes de error como "Error de red".
Comparemos brevemente el brindis y el modal.
Muy sencillo. Toast es un recordatorio ligero que no es necesario apagar manualmente. Un modal es un recordatorio de que debe cerrarse manualmente. Cuál usar, solo piense desde la perspectiva del usuario. Por ejemplo, algunas personas dicen que se deberían volver a solicitar excepciones. ¿Puede ser tan absoluto? No puedes. Por ejemplo, si te gusta una página y te recuerda "Ya te gustó", ¿necesitas que te lo recuerden nuevamente? Por supuesto, con unas tostadas basta. Asimismo, ¿es necesario utilizar consejos ligeros para tener éxito? Por ejemplo, dice "Gracias por su participación, el personal se comunicará con usted dentro de 3 a 5 días hábiles". Ha pasado tanto tiempo, ¿puede hacer un brindis? ¿Podrás esquivarlo?
¿Qué interfaz es adecuada para mensajes emergentes? En pocas palabras, siempre que no tenga nada que ver con la visualización de la interfaz de usuario, es mejor utilizar mensajes emergentes. Por ejemplo, estos escenarios:
Hablemos de errores como carga de datos y desconexión. Los modales se utilizan a menudo porque pueden interceptar las acciones del usuario y evitar cargas repetidas. Además, puede darle al usuario tiempo suficiente para ver la causa del error y evitar reintentos innecesarios.
Luego dice que el contenido de los datos es incorrecto, ya sea un envío de formulario o algo similar, el mensaje de error suele ser un brindis. Después de todo, un usuario podría completar accidentalmente el mensaje incorrecto y simplemente echar un vistazo rápido y corregirlo rápidamente.
Por último, hay dos formas de decir errores 401. Una es usar un modal, porque el usuario generalmente se ve obligado a ir a la página de inicio de sesión, pero antes de redirigir, el usuario debe comprender por qué quiere redirigir, por lo que primero puede solicitar el modal y hacer clic en Aceptar para saltar a la página de inicio de sesión. . El segundo es usar brindis, pero primero debe saltar y luego solicitar el brindis "Inicie sesión primero" en la página de inicio de sesión.
Barra de advertencia
La barra de advertencia es un componente emergente que se puede cerrar, es permanente y no impide que el usuario continúe operando. en la parte superior de la página o cerca del área de operación del usuario. ¿En qué escenarios se utiliza una barra de advertencia?
Por ejemplo, el editor MD enviará automáticamente datos al servidor siempre que los ingrese, y la frecuencia es muy rápida. A veces, el guardado puede fallar debido a problemas de red o del servidor. En este momento, aparecerá una barra de advertencia en la parte superior de la página durante un tiempo prolongado, indicándole que no se pudo guardar, pero aún puede continuar escribiendo. Cuando la red sea normal, el brindis desaparecerá automáticamente. Por supuesto, también podrás apagarlo manualmente.
En resumen, cuándo usar barras de notificación, modales y de advertencia depende del producto y del negocio, y se debe prestar atención a priorizar los errores reportados en el contenedor y ocultarlos.