Si yo, como otro usuario final, entendí bien, es lo mismo que estoy experimentando con bastante frecuencia. Un tema se está recargando y en un corto momento, un parpadeo o dos, el foro muestra una publicación antigua y luego salta al último borde de visita. Me sucedió hace unos momentos y esperaba el salto, pero dejó de mostrar algo antiguo.
Entonces… no sé programar, pero eso suena como un error extraño de estilo de tiempo de espera, como si todo estuviera siempre en el estado límite y, después de un incidente de retraso muy corto, Discourse intenta mantener el ritmo y muestra lo que sea que esté en pantalla en ese momento.
Cuando habilité el modo “lento”, puedo ver que se llama a LockOn para bloquear una publicación en la pantalla, pero no puedo verla ni siquiera representada, por lo que el posicionamiento está muy desfasado.
Toda la clase LockOn es un poco un hack, en este caso, ¿quizás en lugar de bloquear y almacenar en caché una posición, hacemos algo más? ¿Existe un mecanismo para llamar a LockOn más tarde, después de que la pantalla ya esté poblada con temas renderizados?
Muchas gracias por los pasos de reproducción claros @Don
¡Sí, eso es! Están sucediendo dos cosas al mismo tiempo
El servicio del control deslizante de carga necesita eliminar la clase still-loading del cuerpo.
LockOn necesita desplazarse al lugar correcto.
Ambos estaban programados en la parte afterRender del ciclo de ejecución de Ember. Y dado que las cosas de ‘lock on’ están técnicamente programadas primero, se ejecutaron primero. Y así LockOn se estaba ejecutando mientras todo el HTML de la publicación estaba en el DOM, pero todavía tenía display: none.
Esta PR moverá la eliminación de la clase still-loading a la parte de ‘render’ del ciclo de ejecución, lo que significa que cualquier otra cosa que programe cosas en afterRender se ejecutará una vez que todo se haya renderizado y sea visible:
¡De acuerdo! No quería tocarlo como parte de la corrección de este error, pero creo que deberíamos intentar eliminar todos esos hacks.
Leyendo los comentarios en el archivo, parece que se introdujo originalmente (¡hace 10 años!) para contrarrestar las funciones de ‘restauración de desplazamiento’ del navegador. Hoy en día, usamos history.scrollRestoration = false para deshabilitar esa función del navegador, por lo que creo que eso hace que la mayoría de los hacks antiguos sean redundantes.
Probablemente sea mejor probar este tipo de cambio sensible a través de un componente de tema primero, y luego, si todo se ve bien, podremos fusionarlo en el núcleo. Me imagino que eliminar LockOn solucionará muchos otros casos extremos que tenemos con la posición de desplazamiento del tema. Intentaré probar esto en las próximas semanas
