Para empezar, discutamos las expectativas clave en la implementación de un sistema centralizado de manejo de errores en nuestra aplicación web. Aunque los requisitos de las aplicaciones pueden ser diferentes, las siguientes son algunas de las tareas que como ingenieros encontramos regularmente.
Traducir los códigos de error a mensajes legibles para los humanos
Cuando nuestra aplicación implica un backend que interactúa regularmente con las entradas del usuario, es común tener nuestro propio conjunto de errores específicos de la plataforma definidos en el backend. Por ejemplo, el backend de una aplicación ToDo tendría errores como UnknownTodoID, TodoStateError, DuplicateToDo etc. Estos errores no están bajo el conjunto estándar de tipos de errores HTTP y son específicos de la plataforma. Por lo tanto, el backend debe comunicar el error al usuario final de manera significativa. Aunque tener un mapeo de código duro en la aplicación de frontend especificando el mensaje de error para el ID de error funciona para una aplicación más pequeña, con el aumento de las complejidades es mejor que el mensaje de error se origine en el propio backend. Nuestro controlador de errores en el frontend debería ser capaz de capturar el error y el mensaje de error del backend y mostrarlo al usuario.

Punto único de manejo
Los errores, cuando se manejan, deben tener un punto central de control. Por ejemplo, puede decidir más tarde que todos los errores deben disparar un evento de error a un servidor de registro para su posterior análisis. Si los errores se pasan directamente de las llamadas de la API a los estados de error, acabaríamos cambiando todos esos puntos de origen de los errores. (Alternativamente, un oyente del almacén de errores podría trabajar en el contexto de Redux, pero esto podría agotar el rendimiento de forma significativa).
Menos Trabajo Futuro
En el desarrollo de cientos de búsquedas de API, siempre preferimos que el código de manejo de errores esté automatizado en la medida de lo posible. En un escenario ideal, no deberíamos comprobar explícitamente si hay errores en el objeto de respuesta de una API. Más bien, el mecanismo de manejo debería calcularlo utilizando el contenido de la respuesta.
Con el requisito anterior en mente, podríamos ahora llegar a un diseño para nuestro manejador de errores centralizado. Aunque podría haber muchos enfoques de diseño para abordar el mismo problema, el siguiente es un enfoque listo para la producción que utilizo cuando la aplicación usa una tienda Redux.
- Primero, decida la forma del objeto de respuesta que espera de sus fuentes de datos.
- Estructurar los puntos de interacción del API para asegurarse de que la respuesta de los objetos y la forma esperada coincidan.
- Crea un reductor de errores que observa cualquier error que «ocurra» en la aplicación y lo registra en el estado de error.
- Crear una estructura para disparar errores manualmente con acciones de error.
- Finalmente, crear componentes reutilizables para mostrar los errores.