Estadísticas de usuario incorrectas en el directorio de usuarios

[Moin]

Creo que pude reproducirlo en un Codespace creado a partir de esa rama.

Lo intenté porque hoy noté que a veces los números en el directorio de usuarios son incorrectos y pensé que tal vez se deba a que los usuarios no se cargan.

Ejemplo de los números incorrectos que noté:

Este es el directorio de usuarios tal como se ve al abrirlo. Período de tiempo semanal, ordenado por “me gusta” recibidos. Ahora cambio el orden a “Lecturas”:

Luego cambio el período de tiempo a “hoy”:

Y lo mismo (hoy, ordenado por lecturas) después de una recarga

Como puedes ver, el número de lecturas de @lcor hoy cambió después de la recarga. Antes, no encajaba en la lista ordenada.
En realidad, las 214 son las lecturas de esta semana:

Esta no fue la única cuenta donde los números mostraban el recuento semanal en lugar del de hoy al realizar estos pasos. Hay más usuarios que parecen no estar en el lugar correcto, donde en realidad se muestran los números semanales.

Próximos usuarios en la lista antes/después de la recarga

¿Crees que es el mismo problema o hay 2 problemas coincidentes en este momento?

[Moin]

Todavía puedo reproducir esto con los pasos anteriores. Por ejemplo, las estadísticas de thoka son incorrectas antes de la recarga:

Y correctas después de la recarga:

[zogstrip]

Puedo reproducirlo aquí en meta

Antes de actualizar

Después de actualizar

Los números son diferentes, pero lo más importante es que siempre hacemos dos solicitudes al endpoint directory_items (una con y otra sin la extensión .json), pero una de ellas tiene parámetros incorrectos

Sin embargo, no puedo reproducirlo localmente, tengo dos solicitudes diferentes, pero están en endpoints diferentes (groups/search.json vs directory_items)

–

EDIT: habilitar el componente temático user card directory no cambia el problema/comportamiento.

[Moin]

¿Intentaste añadir más usuarios a tu instalación local? Me pregunto si necesitas más de 50 usuarios, para que no se carguen todos a la vez.
Creo que los usuarios que muestran números incorrectos fueron los que no eran visibles al principio.

[zogstrip]

Intenté almacenar algunos datos en caché localmente para no realizar solicitudes innecesarias en cada cambio de orden/columna de clasificación.

PERF: cache requests when navigating user directory

Pero no estoy seguro de que solucione la solicitud doble / condición de carrera que ocurre en producción, ya que no pude reproducirla localmente

[zogstrip]

Hmmm, esto no ha solucionado el problema de la doble solicitud y ahora veo un error de JS con “loadMore” llamándose en undefined

[zogstrip]

Esto terminó siendo una desagradable “condición de carrera” entre el “centinela” que usamos para detectar cuándo necesitamos activar la acción de “cargar más” y la representación de las filas en el directorio de usuarios

El Problema

Cuando había al menos 50 usuarios, la página /u (directorio de usuarios) activaba loadMore inmediatamente al cargar por primera vez, antes de que el usuario pudiera desplazarse hacia abajo. Esto provocó que una segunda página de resultados no deseada se cargara automáticamente.

Causa Raíz

Condición de carrera de tiempo durante la carga inicial de la página:

1. El usuario navega a /u
2. controllers/users comienza a cargar datos (isLoading: true)
3. La plantilla se renderiza con ConditionalLoadingSpinner mostrando el spinner
4. Llegan los datos, isLoading se convierte en false
5. El spinner se oculta, DirectoryTable comienza a renderizar 50 usuarios
6. El centinela de LoadMore se inserta en el DOM
7. IntersectionObserver se crea y comienza a observar inmediatamente
8. En este momento, la tabla todavía está calculando el diseño/expandiéndose a la altura completa
9. El centinela es brevemente visible en la ventana gráfica (~292px desde la parte superior) antes de que la tabla se expanda
10. El observador detecta la intersección → activa loadMore
11. La tabla termina de expandirse a la altura completa (~3689px)
12. El centinela se mueve a la posición correcta (~3959px, debajo de la ventana gráfica)

El observador fue “demasiado entusiasta”: comenzó a observar antes de que el contenido terminara su diseño, capturando el centinela durante el breve momento en que la tabla aún no había alcanzado su altura final.

La Solución

Retrasar la creación del observador hasta que el contenido esté listo:

Se agregó un parámetro @isLoading a LoadMore que evita que se cree el IntersectionObserver cuando el contenido aún se está cargando.

Cómo Funciona Ahora

Carga de página → isLoading=true → Modifier omite la creación del observador
             ↓
Carga de datos → isLoading=false → Modifier se vuelve a ejecutar, crea el observador
             ↓
Tabla completamente expandida → Centinela en la posición correcta (debajo de la ventana gráfica)
             ↓
El usuario se desplaza hacia abajo → El centinela entra en la ventana gráfica → loadMore se activa ✓

---

FIX: eager "load more" in users directory