Mejoras gráficas

Desarrollo
101

@pierre-gilles,

¿Podrías echar un vistazo al parche? ¿Es mejor para ti?

102

@Terdious Te hice una revisión:

103

Te respondí sobre tus preguntas de la PR.

Hice las modificaciones para separarme de la parte Overkill, pero vuelvo al mismo punto, me queda un momento particular donde no entiendo por qué tengo un resultado incorrecto:
En algunos de mis dashboards (tengo la impresión de que es cuando hay muchos elementos, la altura recuperada es incorrecta al cargar la página. Luego, componentDidUpdate toma el relevo y el valor vuelve a ser correcto. Por lo tanto, creo que recupera la altura cuando la página no está completamente cargada… Pero no sé cómo encontrar la funcionalidad correcta. ‹ resizeObserver › y ‹ mutationObserver › funcionaban, estaba contento. Y vi en stackoverflow que era recomendado, pero también que era muy rápido.

Por ejemplo, aquí, el console.log me da 2371 cuando la altura real es 3385. Una vez que se produce una actualización, recupero el valor correcto.

image
image679×285 14.9 KB

image
image1903×952 119 KB

No dudes en guiarme sobre mejores pistas si tienes en mente cómo manejar mejor la posición ‹ sticky › en este caso.

Hice push de las modificaciones.

104

Después de probarlo, debo admitir que no siempre encuentro interés en el sticky, cuando estás al final de la pantalla incluso puede ser bastante confuso para el usuario:

Haces clic, pero no pasa nada visualmente.

Por lo tanto, al final, me pregunto un poco sobre su utilidad ^^

¿Qué opinas?

105

Me viene bien ^^

106

Retira eso de ahí, solo guarda el botón de arriba, es suficiente para mí y creo que funciona mejor :slight_smile:

107

¡Hecho y subido! Tienes razón, me gustaba, pero al final no está tan mal así ^^

¡Gracias por tu análisis!

108

He respondido a tu comentario:

109

Hmmm ^^ Me has hecho una pregunta interesante ^^ En realidad, eso permitía preparar el terreno de manera dinámica. Pensé que si algún día aumentabas el tamaño de visualización (¡sería genial ^^) habría permitido pasar a 4 o 5 columnas fácilmente ^^

Pero sí, si nos quedamos con tres columnas, ¡quedaría bien!!

110

¿O por qué no usar una flexbox clásica?

111

Esto está realmente relacionado con mantener el máximo de espacio para las columnas a rellenar. He pasado a porcentajes:

  const columnStyle = {
    '--column-width': boxesLength === maxBoxes ? `calc(100% / ${maxBoxes})` : `calc(93% / ${boxesLength})`
  };
  const addButtonStyle = {
    '--add-button-width': boxesLength < maxBoxes ? 'calc(7%)' : '0'
  };

Pero si no, no pasa nada, podemos quedarnos con el ‹ col-lg-10 › / ‹ col-lg-2 › cuando hay 2 columnas o menos. El problema solo se plantea para las 2 columnas o cuando no puedo hacer un ‹ col-lg-(11/2) › ^^

112

Oui oui no cuestiono el funcionamiento ^^

Pero ¿por qué no usar flexbox CSS para hacer esto?

Tienes una columna fija: la última columna con el botón

Y 1, 2 o 3 columnas que deben tener un tamaño dinámico que es simplemente el espacio restante dividido por el número de columnas (y es automático, nada que codificar, es CSS)

113

Me permito aportar mi granito de arena, apoyo la idea de tener la posibilidad de hacer de 1 a N columnas, lo que permite trazar una dirección sobre cómo gestionar las columnas, especialmente con las pantallas cada vez más cualitativas, en pantallas grandes las 3 columnas representan el 50% del ancho de la página.

De lo que he entendido, es Bootstrap detrás, un pequeño col-xl-N que depende del número de columnas es factible, incluso permitiendo de 1 a 4, por ejemplo, para poder conservar un múltiplo de 12. Pero en mi opinión, 3 sigue siendo un poco ligero en pantalla grande. Y el problema de llegar a 5 es la gestión de este múltiplo en Bootstrap, muchos problemas por poco. Pero para 4 me parece un buen compromiso.

Otra opinión, no sobre la parte puramente de columnas, pero sería interesante tener un panel de expansión en la parte de edición para las tarjetas en las columnas. Por ejemplo, para tarjetas grandes como los gráficos, si tienes 3/4, se vuelve rápidamente difícil mover las tarjetas. Podríamos simplemente añadir un botón a la izquierda del botón para mover que sería ‹ plegar ›. Solo una idea :slight_smile:

114

Al final, propones mantener el modo de reorganización (« Reordenar ») iniciado para dispositivos móviles (o pantallas pequeñas) que @pierre-gilles desarrolló.

1000020407
10000204071080×2316 162 KB

De hecho, en mi opinión, tiene sentido, especialmente como dices cuando ya hay muchos bloques de gran tamaño.

115

Personalmente, he modificado el CSS para aumentar el ancho de los bloques, porque si no, como dices, hay mucha pérdida de espacio en la pantalla…

image
image1919×617 97 KB

.container {
max-width: 90%; 
}

image
image1919×617 102 KB

116

Ah excelente, acabo de probar con 80% y es realmente genial.

¿Has creado un Dockerfile donde obtienes el Docker de Gladys y modificas el archivo CSS cada vez, ¿verdad? :slight_smile:

117

Pierre-Gilles me había indicado usar una extensión como CustomCSS que permite modificar automáticamente el CSS al cargar la página.

image
image624×420 62.3 KB

118

Hola @pierre-gilles,

Gracias por tu ayuda y disculpa por el malentendido inicial. Los parches están hechos, todo en CSS y funciona muy bien en mi caso. Además, he ganado 4 advertencias de ESLint.

Te dejo revisar (y ver si es lo que tenías en mente) la PR y decírmelo.

Voy a revisar los binarios ^^

119

Gracias @Terdious por los parches, ¡así está mucho mejor :)!

Está mucho más limpio, pasamos de un gran PR en términos de código a tres veces nada, ¡es genial :ok_hand:! Menos código = menos errores.

Tengo un comentario menor sobre algo muy menor, pero el resto está bien para mí:

120

¡Hola @Terdious :slight_smile: Vengo a preguntar sobre mi último mensaje.

¡Sería genial que esto se implementara en Gladys rápidamente, es una función realmente increíble!