Categorías
Desarrollo web Temporada 2

SleepTracker 0.1-b

La siguiente iteración del desarrollo de la app se centra en el ciclo de inserción y finalización de una entrada.

Inserción

Funciones

Lanzada al presionar el boton de nueva entrada, automaticamente genera una entrada con la fecha y la hora del instante de la inserción.

Para evitar duplicados, comprueba que en los últimos 7 eventos no haya ninguna inserción que se haya realizado en las últimas 12 horas: en caso de serlo, lanzaría un error.

Si todo está correcto, devuelve la nueva inserción.

Presentacion

Esta fase muestra disponibles aquellos botones que, dados los datos obtenidos, pueden ser usados por el usuario:

En un primer momento la idea era realizar una consulta al backend mediante la que obtener las últimas entradas y comprobar si estas estaban activas.

En esta primera versión he decidido que resultaba más sencillo comprobar simplemente si existía una entrada abierta y no permitir al usuario crear nuevas hasta no cerrar la abierta.


✅ En caso de no haber entradas activas, el link new sleep está activo.
❌ En caso de haber entradas activas, el link New Sleep está desactivado y aparece la opción de cerrar el ciclo

Finalización

Por último, activamos la opción de poder evaluar la entrada y cerrar definitivamente el proceso cambiando el flag de completed a TRUE.

De esta forma, el ciclo de entrada se reinicia, el usuario ya tiene la posibilidad de insertar una nueva entrada y la base de datos almacena la anterior como completada con los datos necesarios: fecha de inicio, fecha de fin y evaluación de la calidad del sueño.

La forma de presentar esta evaluación ha sido mediante una escala de estrellas donde 1 es el peor valor y 5 el mejor:

Con esto cerraríamos ya el proceso de inserción y nos podremos centrar a partir de ahora en el análisis de datos.

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

Log 1.6: DSM5Tool – Versión 0.2.3

Voy a aprovechar que tengo el devlog para ir publicando los avances que haga respecto a las distintas versiones del DSM5Tool. De esta manera puedo usarlo como recordatorio de las tareas pendientes que tenía proyectadas:

Las mejoras propuestas para la versión 0.2.3 son:

  • Refactor de TrastornoEdit
  • Bloque #1 de trastornos completado
  • UX/UI del formulario
  • UX/UI de TrastornoDetail
  • Análisis de datos: Técnicas
  • Diseño de implementación de técnicas»

Refactor de TrastornoEdit

Completado

🟩🟩🟩🟩🟩

He editado bastantes de los hooks [https://dev.mdgmedia.es/2021/01/25/dsm5tool-usando-custom-hooks/] que tenía definidos para hacerlos más eficientes y reducir la cantidad de código dedicado a ello.

He extraído un par de funciones más, creando un archivo dedicado para ellas:

export const addSubCriterio = (
  target,
  i,
  j,
  trastornoCriterios,
  setTrastornoCriterios
) => {
    const newTrastornoCriterios = [...trastornoCriterios];

  if (newTrastornoCriterios[i].Subcriterios) {
    newTrastornoCriterios[i].Subcriterios[j] = target.value;
  } else {
    const newCriterio = {
      Descripcion: newTrastornoCriterios[i].Descripcion,
      Subcriterios: [target.value],
    };
    newTrastornoCriterios[i] = newCriterio;
  }
  setTrastornoCriterios(newTrastornoCriterios);
};


export const addTrastornoCriterio = (target, i, trastornoCriterios, setTrastornoCriterios) => {
    const newTrastornoCriterios = [...trastornoCriterios];
    const newCriterio = {...newTrastornoCriterios[i],
      Descripcion: target.value,
    };
    newTrastornoCriterios[i] = newCriterio;
    setTrastornoCriterios(newTrastornoCriterios);
  };


export default { addSubCriterio, addTrastornoCriterio };

La idea es tener localizadas todas las funciones dentro de la misma carpeta para, así, poder reutilizarlas de forma cómoda y rápida.

Bloque #1 de trastornos completado

Completado

🟩🟩🟩🟩🟩

Esta tarea es, probablemente, la más aburrida de esta versión, porque se trata de ir configurando manualmente los distintos trastornos. El objetivo de esta primera fase es completar 50 trastornos con su descripción y criterios diagnósticos. De esta forma, en diez fases alcanzaremos los 477 diagnósticos que actualmente tiene la aplicación almacenados.

UX/UI del formulario

En progreso

🟩🟩🟩🟩🟩

He encontrado algunos modelos que puede resultar interesante implementar. Una de las cosas que veo más posibles es la de tabular la información.

8cd0dd2ab88ecd6459d1ede16cde49e7

Me gustan este tipo de diseños sencillos y limpios.

También me resulta interesante trabajar con tonos de grises y colores pastel suaves, que facilitan mucho el trabajo de inserción de datos. Esto me ha llevado a plantearme también que en futuras versiones, tal vez la 0.2.6 o la 0.2.7, podamos plantear la posibilidad de introducir un modo oscuro.

Tras los cambios, el formulario de edición de trastornos ha quedado más sencillo y limpio:

UX/UI de TrastornoDetail

Completado

🟩🟩🟩🟩🟩

He modificado el diseño de TrastornoDetail para hacer más sencilla la forma en la que se muestran los criterios y los subcriterios:

  • Cada criterio ahora está precedido de una letra.
  • Cada subcriterio está integrado dentro del criterio de forma que quedan claramente diferenciados.
  • Visualmente es más vistoso, puesto que se añaden tonos azules que mantiene la tónica cromática de la aplicación.

Análisis de datos: Técnicas

Completado

🟩🟩🟩🟩🟩

He dado con una web bastante interesante que relaciona una gran cantidad de trastornos con terapias respaldadas por su eficacia contrastada científicamente. Además, he planteado una forma de mostrarlas de tal manera que sea sencillo identificarlas y me permita añadir información en futuras actualizaciones. Este es un pequeño prototipo que he hecho basándome en esa idea.

Diseño de implementación de técnicas y tratamientos

Completada fase 1

🟩🟩🟩🟩🟩

Ya tengo lista la definición básica del objeto ‘técnica’. La idea es crear un documento nuevo en MongoDB y enlazar esta información con el actual documento de trastornos.

Con esto doy por finalizada la versión 0.2.3, que ya está subida a GitLab y me pongo manos a la obra con la versión 0.2.4.

Categorías
DSM5Tool Temporada 1

Log 1.3: DSM5Tool

Uno de los grandes problemas que he tenido que gestionar estas primeras semanas ha sido que, en determinado momento, al trabajar solo, me he sentido algo perdido.

Esa sensación suele traer consigo falta de motivación y, en muchas ocasiones, pérdida de interés por el proyecto. Por eso, para evitar que eso suceda, puede resultar interesante desarrollar cosas en paralelo que vayan a ser útiles en un futuro.

La idea de DSM5Tool es sencilla: un índice de los distintos trastornos que aparecen en el manual de diagnóstico de psicología DSM-5 (https://www.psychiatry.org/psychiatrists/practice/dsm).

El objetivo de esta miniapp es la de coger algo de soltura con ReactJS y con Chakra UI para ir avanzando de forma más sostenida.

Por ahora ya he completado la primera fase de la aplicación que incluye:

  • Estructura de datos básica
  • Buscador por trastornos
  • Buscador por categorías/subcategorías
  • Listado de criterios diagnósticos.

Todavía me falta definir completamente la estructura de los datos, puesto que el DSM-5 no sigue un esquema predeterminado y eso complica un poco la forma de parametrizar la información.

En la siguiente iteración del proyecto mis objetivos son:

  • Concluir la estructura de los datos
  • Buscador por criterios/etiquetas
  • Información completa por trastorno

Por ahora la definición de mi estructura de datos sigue el esquema:

export const dsm = [
  {
    categoria: "Trastornos del desarrollo neurológico",
    tipos: [
      {
        tipo: "Discpacidades intelectuales",
        trastornos: [
          {
            codigo: "F70",
            trastorno: "Discapacidad intelectual leve",
            indice: "317",
            descripcion: "La discapacidad intelectual (trastorno del desarrollo intelectual) es un trastorno que comienza durante el período de desarrollo y que incluye limitaciones del funcionamiento intelectual como también del comportamiento adaptativo en los dominios conceptual, social y práctico.",
            criterios: [
              "Deficiencias de las funciones intelectuales, como el razonamiento, la resolución de problemas, la planificación, el pensamiento abstracto, el juicio, el aprendizaje académico y el aprendizaje a partir de la experiencia, confirmados mediante la evaluación clínica y pruebas de inteligencia estandarizadas individualizadas.",
              "Deficiencias del comportamiento adaptativo que producen fracaso del cumplimiento de los estándares de desarrollo y socioculturales para la autonomía personal y la responsabilidad social. Sin apoyo continuo, las deficiencias adaptativas limitan el funcionamiento en una o más actividades de la vida cotidiana, como la comunicación, la participación social y la vida independiente en múltiples entornos, tales como el hogar, la escuela, el trabajo y la comunidad.",
              "Inicio de las deficiencias intelectuales y adaptativas durante el período de desarrollo."
            ]
          }
        ]
      }
    ]
   }
  ]

Pronto os mostraré partes del diseño gráfico y de cómo avanza la parte de la lógica tras la aplicación.

Categorías
Temporada 0

Log 0.3

Objetivos:

  • Traslado de Hooks a Redux
  • Interfaz

Migrando un proyecto a Redux

Pese a que no creo que utilice en mis proyectos la solución de Redux, el curso me ha venido bien para entender su concepto.

Uno de los problemas que puede presentar trabajar con Hooks en React es que la información suele viajar en un único sentido: de los componentes padre a los componentes hijo.

Existen alternativas para resolver esta unidireccionalidad, pero originalmente este mecanismo no estaba pensado para ir en otra dirección.

Así, cuando queremos emplear un valor en distintas partes de nuestra aplicación de forma generalizada, trabajar con Hooks puede resultar engorroso.

Redux es, simplificándolo, un gestor de variables globales que puede accederse desde cualquier punto de tu aplicación.

La forma de acceder a lo que se conoce por Store se hace en dos fases: Primero definimos la store en el nivel más alto de nuestra aplicación:

//..
import store from './store'
import { Provider } from 'react-redux'

ReactDOM.render(
  <Provider store={store}>
    <App ></App>
  </Provider>,
  document.getElementById('root')
)

De esta forma, la store está disponible en toda nuestra aplicación, siendo tan sencillo acceder a ella como:

//..
import { useDispatch, useSelector } from 'react-redux'

const users = useSelector(state => state.persons)
const dispatch = useDispatch()

En el primer caso, useSelector nos extrae la información de la store (en este caso el objeto ‘persons’).

En el segundo, creamos una variable dispatch que va a ser la encargada de lanzar los que son conocidos como «reducers», funciones que permiten acceder al contenido de la store para modificarlo:

import userService from '../services/users.js'


const personsReducer = (state = [], action) => {
  switch(action.type){
    case 'SET_PERSONS': {
      return action.data
    }
    default:
      return state
  }

}


export const setPersons = () => {
  return async dispatch => {
    const persons = await userService.getAll()
    dispatch({
      type: 'SET_PERSONS',
      data: persons
    })
  }
}

export default personsReducer

Este es un ejemplo básico de reducer, en el que ya incluimos el método para acceder a él y lo exportamos directamente. De esta forma podemos usar dispatch llamando directamente al método del reducer y dejar que éste se encargue de toda la lógica: tanto la de la store de redux como la de la base de datos.

La migración ha sido sencilla en general, aunque tienes que cambiar un poco la perspectiva cuando pasas de Hooks a Redux porque ni funcionan igual ni se usan para lo mismo.