los gauges presentan información que tiene más sentido en el contexto de
etapas (comidas y glucómetros) mientras que la mbiota tiene más sentido en
visitas.

se quitó el código tanto de la gráfica como de la adquisición de los datos.

aunque no se recolentan mediante la info de visitas, se agregaron los resultados
disponibles de mbiota a éstas para poder mostrarlas en la misma gráfica, ya que
así tiene mucho más sentido que mostrarlas por separado (la muestra para la
mbiota se recolecta en las visitas, de hecho)

en estas secciones se presenta información por visita, pero los selectores
tenían el título de 'etapa', lo cuál resultaba inadecuado y confuso.

por otro lado, las pruebas por paciente en realidad se refieren a confirmar si
tenemos el resultado de cada paciente o no, así que se cambio el título para que
así se exprese.

en la generación del heatmap, para asegurarse de que no generar errores por uso
de columnas no definidas en una cierta visita (p.ej, 'gelatina' no existe en
visita2), se hacía una intersección de las columnas de los datos de la visita
con las columnas definidas a partir de los protocolos (que es un dict. que dice
que mediciones hay en cada protocolo).

una alternativa era tener un dict por cada visita, pero eso es demasiada
información. lo que se había optado por hacer fue una intersección de todos los
protocolos con la info de las visitas. esto funciona bien, pero tiene la
desventaja de que las columnas quedan desordenadas porque las listas se
convierten a sets (para facilitar la intersección). el problema de las columnas
desordenadas era que no quedaban juntas todas las de un mismo protocolo, lo que
dificulta su localización visual.

para resolver esto, se construyo la lista a partir de las intersecciones de cada
protocolo con la info de la visita (en vez de todos los protocolos, uno por
uno). de esta forma, todas las columnas de un mismo protocolo ya quedan juntas.

en las barras que muestran %s, se muestran números enteros como el porcentaje,
lo cual crea una mala interpretación cuando el dicho % es muy cercano a 100.
si no es 100 cerrado, debe mostrarse como 99. eso lo conseguimos con la función
floor.

con respecto a las gráficas que muestran las coberturas por fuentes de datos,
cambiamos los scatters por bars y se ve mejor.

seguimos presentando sin ordenar, porque así es más fácil localizar a un
paciente en particular.

es la parte en donde lo que intentamos hacer es mostrar, para cada paciente,
cuantas comidas/días de glucómetro tenemos registrados.

inicialmente teníamos  una scatter en donde los pacientes estaban ordenados por
el valor a presentar (comidas o glucómetro). se veía más o menos bien, sobre
todo porque sugiere bien el % de pacientes que están debajo del umbral ... pero
no deja identificar a los pacientes que están bajo el umbral porque no se
muestran todas las etiquetas.

pensamos que con un heatmap podíamos mejorar esta visualización y hasta poner
una sola gráfica con las dos mediciones, pero no tuvo caso porque las escalas
son diferentes.

la mejor solución fue poner el scatter pero sin ordenar. de ese modo es fácil
ver quien está abajo del umbral.

no estaba ajustado al ID de los pacientes.

estas gráficas mostraban un scatter y un hist de algunas de las
mediciones
que se hacen a la población. casi todas eran QS -con adición de IMC-

ahora, se puso un selector que permite al usuario escoger el grupo de
variables que quiere visualizar. además, un selector adicional permite
escoger entre ver a toda la población junta o una separación de M/F.

la población junta muestra el scatter + la distribución de cada
variable. la población separada solo muestra el scatter para cada
grupo poblacional.

en cada grupo de variables, es posible definir una lista de las
variables que no se van a mostar. Pej, 'glucagon' en las de QS.

todas las gráficas que se presentan aquí son generadas con datos de
visitas que se obtienen del endpoint. el archivo 'inventario.csv' se
leía pero esos datos ya no se usaban. quizá fue un legado del original
'dinamyc'

en esta app, cuando se mostraban estadísticas de comidas (ver commit
anterior), los dato se leían del archivos 'todos-foods'.
se quita ahora esa lectura y las asignaciones/modificaciones que se
hacían al respectivo dataframe.

se calculaba una gráfica scatter que no aparecía en ningún panel.

son las mismas que ya están en 'estadisticas_comidas' y desde ahí ya
se actualizan usando un endpoint.

para que el el eje Y de la gráfica corresponda con los ids de los
pacientes en vez de una simple enumeración, usamos dichos ids como
índice del dataframe.

dado que este df se construía originalmente mediante la lectura de un
archivo, se hicieron todos los cambios para ajustar el DF de
clickhouse a este otro formato.

para hacer estos ajustes se usan un par de funciones de
nutri_utils (que se añadieron casi ex-profeso a esta biblioteca).

ahora ya no se necesita actualizar ningún archivo para correr el app
de estadísticas de comidas: toda la info viene de la app de
clickhouse.

se sustituyeron los rangos 'duros' del slider (30,217) por un cálculo
dinámico que determina los ids menor y mayor.

como el slider presenta todos los números del rango, hay que verificar
que un valor seleccionado del slider corresponde a un paciente que si
tiene comidas registradas. se simplificó un poco este proceso (que
antes sacaba una lista de 'no-presentes' para comparar con ella, pero
que ahora se hace con la negación de los 'si presentes')

estos archivos contenían por separado la info de las comidas de la app
y las de wapp, con formatos diferentes.

el archivo con comidas de la app tiene el mismo formato que la tabla
de comidas en clickhouse, así que esta sustitución fue directa.
la de las comidas de WAPP solo tenía las columnas de hora, pero fue
fácil sustituirla con los datos provenientes de clickhouse (este
último ya proporciona las comidas de las tres fuentes: app, WA,
recordatorios, así que, usando el mismo mecanismo que aprovechamos para
sustituir el file de WAPP por la respuesta de clickhouse, añadimos las
comidas de recordatorios.).

para que el el eje Y de la gráfica corresponda con los ids de los
pacientes en vez de una simple enumeración, usamos dichos ids como
índice del dataframe.

True/False es interpretado como 0/255, así que explícitamente lo
convertía entero  (0/1). Nota: en go.Heatmap no se hace interpretación
de datos, así que True/False no funciona.

es un duplicado de la última figura, con un nuevo dropdown y una nueva
función para generar la gráfica. así, ya tenemos todo listo para solo
modificar la gráfica de modo que envíe lo que queremos -que en este
caso será un heatmap-

los dos dropdowns quedan arriba, en un único row
luego la gráfica
luego los dos sliders, en un row cada uno.

ahora todos los controles y la gráfica son divs consecutivos.
todos los divs son wrappers.
cada control está encapsulado en un div que contiene su etiqueta y su control

ponemos los controles en una caja flex en fila y ponemos la gráfica
compuesta en un wrapper simple

tambén se fusionó en una gráfica previa

ahora inmersa en una combinación de bullet y scatter

es la gráfica conjunta de bullets y scatter para apreciar la cobertura.

para fusionar nuestras dos secciones en una sola, más informativa.

en el commit anterior la incluimos en un mismo row con los otros pies