La idea de este proyecto es, dada esta API, realizar una página usando React, Redux y cumpliendo los requisitos del curso realizado para General Assembly.
Como puede apreciarse en la imagen, la idea es contar con una 'landing page', la página de trabajo, que llamaremos 'chest' y un 'about' donde se informará debidamente del proyecto.
(Nota: chest ha sido renombrada a Vade Mecum.)
En Vade Mecum, veremos un listado completo de los elementos que aparecen en la API y contaremos con un drop-down donde podremos elegir el tipo de elemento que queremos ver y un cuadro de texto donde buscar palabras clave. Adicionalmente, y si el tiempo lo permite, trataremos de añadir secciones de equipamiento pormenorizadas en el drop-down que no forman parte de la API inicial y que requeriría compartimentarlo a mano. En el ejemplo de la imagen, el usuario ha seleccionado swords, que forma parte del equipo que podremos encontrar en el juego.
El proyecto se desarrolla en React con TypeScript desde Create React App y usa React Redux Toolkit para poder pasar información de una forma más cómoda entre componentes. Las cuatro webs, siendo la cuarta dinámica y distinta para cada elemento que el usuario quiera ver, serán controladas por React Router. Se usará React Helmet para generar un head independiente a cada página y Styled Components para añadir estilos por componentes (como su nombre indica). Los Test, requeridos para el proyecto, también serán realizados con lo que ya viene incluido. La codificación de todo el proyecto hará usando Visual Studio Code.
Se ha utilizado React-Markdown para poder redactar contenido en la página sin tener que recurrir al engorroso método manual. En cualquier caso, se pretende dejar una sección pormennorizada de los elementos utilizados dentro de about en la propia página.
Adicionalmente, destacar que se ha protegido el cuadro de búsqueda para que no pueda inyectarse código por cuestiones de seguridad. También se han cubierto las rutas erroneas, tanto las de páginas como las posibles entradas erroneas desde el Vade Mecum.
Inicialmente, pretendía usar React Helmet, pero el proyecto se ha desarrollado en TypeScript y Helmet ya ha dejado de sar actualizado por lo que usé la versión Async indicado. También he tratado de usar MDX-Js - Markdown for the Component Era, pero resultó plantear demasiados problemas y, de todas formas, este proyecto no cuenta con demasiado texto como para justificar la inversión en tiempo. Se optó por usar React-Markdown, que funcionó sin problemas pese a ser más limitado.
Los principales problemas que he encontrado en el desarrollo del proyecto se han definido en conseguir que los distintos elementos utilizados se "lleven bien unos con otros" y no se produzcan fallos indeseados, a veces ni siquiera detectables en producción.
React y su entorno se comportan como un ente vivo, en constante crecimiento y evolución. A veces cuesta encontrar documentación actualizada y acomodarse a los distintos cambios. Aun así, sus equipos son profesionales y, entre unos y otros, he conseguido ir superando los distintos obstáculos.
Una vez conseguido el scaffolding de la página, todo ha ido bastante rápido y sin demasiados problemas. La decisión de usar TypeScript se ha tomado por dos razones. En primer lugar para añadir algo de desafío a este proyecto, en segundo lugar porque, a mi entender, es una forma mucho más adecuada de trabajar, por engorrosa que pueda resultar a veces. Controlar bien las variables es una magnífica medida para prevenir en la medida de lo posible los ataques externos y es por ello que también se ha bloqueado la única vía de comunicación por parte del usuario de esta web, que no es otra que el cuadro de diálogo search. Dudo que pueda decirse que esta página es inespugnable, pero también dudo que pueda decirse de ninguna.
Las secciones de equipamiento pormenorizadas se han podido añadir y además se ha implementado una memoria que almacena la búsqueda que el usuario había realizado al hacer click en un elemento y flechas que permiten ir al siguiente o anterior elemento basándonos en su ID o volver al Vade Mecum con nuestras opciones guardadas. Si no deseamos reutilizar nuestra anterior búsqueda, se ha añadido un boton de Reset que, además, no requiere recargar datos porque usa las array previamente creadas y deja la categoría y campo de búsqueda a sus valores por defecto. También se ha controlado la posibilidad se superar la última id (389) y nos lleva a la primera si pulsamos siguiente. El último elemento lo he obtenido del array, pero he dejado el número hardcodeado en caso de que no se tuviera acceso a la misma por si a un usuario se le ocurre guardar como bookmark una página de elemento. Este juego tiene ya algunos años y es poco probable que la API se actualice.
También se ha añadido un prompt que nos muestra el número de elementos a nuestra disposición, dependiendo claro está de los parámetros de búsqueda que hayamos introducido. Incluso se ha controlado el hecho de que no haya resultados, obteniendo un "No hay coincidencias" en lugar de "Hay 0 elementos".
Como últimos retoques, he añadido una segunda utilidad de la API donde se almacenan los enemigos que encuentras cuando comienzas la partida en un modo de dificultad superior conocido como Master Mode en el juego. Los datos se han tratado en un Vade Mecum diferente por generar conflictos de ID. Asimismo, en este Master Vade Mecum, en luar de enseñar la ID se ha optado por mostrar como elemento de orden el índice de la tabla creada, para que el usuario no vea números desordenados al recorrer la lista.
Además se ha implementado un sistema para ordenar las tablas antes de mostrarlas, garantizando así que siempre aparezcan en el orden correcto para el usuario. Ambos Vade Mecum han sido optimizados para garantizar el menúr número de importaciones de datos desde la API y una experiencia más rápida al usuario, si bien es cierto que no he encontrado una forma de eludir el hardcodeado en las correspondientes páginas de los elementos, como ya comentara unos párrafos atrás. Hasta encontrar una solución mejor, se ha optado por este método en función de garantizar la mejor experiencia al usuario.
Aparte del problema con el scaffolding, el otro gran obstáculo lo he encontrado a la hora de obtener y preparar los elementos. Esta API no genera una simple tabla, sino una estructura dividida en categorías, lo que representa un problema para renderizar todos los elementos. Es por ello que se ha creado un array elaborada a partir de los datos obtenidos de la API y con ella también los array de las distintas categorías además del array de IDs para el Master Vade Mecum mencionado arriba. Controlar las promesas y otro tipo de siituaciones no se antoja fácil.