Categorías
Desarrollo web

RecipeApp: Log 1

Esta es la última de las mini aplicaciones que quiero desarrollar en esta primera serie y, por tanto, es la que más complejidad quiero que añada.

Por eso, al hecho de implementar el front y el back como TypeScript, le quiero añadir la gestión de la API de recetas mediante GraphQL.

La API de recetas, además, deberá conectar con una base de datos MongoDB donde pretendo almacenar todas las recetas y sus ingredientes.

Mi intención es que el desarrollo de esta solución incluya la posibilidad de una mejora que permita integrarla en un sistema de gestión de recetas bastante más complejo, si llegase el caso.

Objetivos principales

Frontend

  1. Desarrollar un diseño responsive que permita su integración en dispositivos móviles.
  2. La aplicación va a estar gestionada desde una única página pero va a permitir el uso de rutas para acceder a las recetas.
  3. Todo el sistema estará desarrollado en TypeScript

Backend

  1. API conectada con base de datos MongoDB
  2. Gestión de la API mediante GraphQL estandarizando las queries y las mutations.
  3. El backend también estará escrito en TypeScript

Base de datos

Base de datos NoSQL con dos colecciones de documentos principales: recetas e ingredientes, relacionadas entre sí 1:n.

La gestión de los distintos elementos tipados la va a hacer la propia API, puesto que tendrá que añadir elementos de a los objetos definidos.

Así, mi idea es que los Intgredientes sean, en realidad, un objeto que incluya su ID, la cantidad y el peso.

Objetivos secundarios

La implementación del tipo Ingrediente puede abrirme a la posibilidad de introducir datos específicos de los ingredientes, esto es, información nutricional o el precio.

Aunque en la primera versión de esta aplicación no van a tener una utilidad real, quiero dejar preparada la estructura de datas para posibles futuras actualizaciones.

El problema que esto plantea es que su gestión genera alguna capa más de dificultad, tanto a nivel de la gestión de los datos, como de la interfaz de usuario a la hora de introducir nuevos ingredientes.

Categorías
DSM5Tool Temporada 1

Log 1.7: DSM5Tool – Versión 0.2.4

Seguimos con el proyecto después de unos días de relax.

Las mejoras propuestas para la versión 0.2.4 son:

  • Gestión de usuarios
  • Bloque #2 de trastornos completado
  • Página para trastornos: TrastornoPage.jsx
  • Paginación
  • Implementación de técnicas

Gestión de usuarios

🟩🟩🟩🟩🟩

Ya he desarrollado la parte del servicio de consulta

import axios from 'axios'
 const baseUrl = '/api/login'
 const login = async credentials => {
   const response = await axios.post(baseUrl, credentials)
   return response.data
 }
 export default { login }

Además, el frontend ya tiene definido la pantalla de login y ya simula el acceso de usuario

Ya he terminado el backend. Ahora ya no sólo se puede acceder a la parte de la API enfocada al Login, sino también he creado un endpoint para crear nuevos usuarios y la edición de los trastornos requiere ahora de autorización mediante token.

En el frontend todo está más o menos listo, a falta de la actualización de los trastornos puesto que tengo que incluir en la cabecera el token generado.

La base de datos ya dispone de un documento para usuarios al que he modificado ligeramente el esquema inicial: he considerado más útil emplear el correo electrónico como usuario en lugar de andar creando nombres de usuario porque añadía una capa de complejidad innecesaria y porque, en realidad, me interesará en el futuro disponer de una base de datos de usuarios a los que contactar mediante email.

interface usuario = { 
	nombre: String,
	email: String,
	password: String,
	tipo: String
}

Con esto zanjo la gestión de usuarios prevista para la versión 0.2.4.

Bloque #2 de trastornos

⬜⬜⬜⬜⬜

Página para trastornos

⬜⬜⬜⬜⬜

Paginación

🟩🟩🟩🟩🟩

A pesar de que existen soluciones como react-pagination, como, en realidad, la aplicación no requiere de un sistema de paginación complejo; he optado por utilizar hooks y desarrollar yo mi propio sistema.

Ahora mismo la aplicación ya pagina correctamente, en bloques de 8 trastornos (por tratarse de una Grid de 4 elementos) y lo hace independientemente del total de trastornos mostrados.

Cada vez que hay un cambio en el motor de búsqueda, como, por ejemplo, seleccionar una determinada categoría, el sistema reinicia la paginación y la adapta al nuevo número de páginas.

Tuve algunas dudas acerca de cuál debería ser la funcionalidad de los botones Sig y Prev, y al final me decanté porque salten un nuevo intervalo de páginas, en lugar de ir moviéndose de una en una.

Por ahora los botones de «…» son meramente decorativos y no añaden funcionalidad.

Implementación de técnicas

🟩⬜⬜⬜⬜

La lista de técnicas avaladas por la evidencia científica está casi completada. Una vez la termine me gustaría centrarme en la implementación de las técnicas en la base de datos y así dejarlo todo lo listo para la parte de integración en el sistema tanto en la parte del front como en la del back.