Estatísticas do usuário incorretas no diretório de usuários

[Moin]

Acho que consegui reproduzi-lo em um Codespace criado com base nesse branch.

Tentei porque hoje notei que às vezes os números no diretório de usuários estão errados e pensei que talvez fosse por causa do problema de que os usuários não são carregados.

Exemplo dos números errados que notei:

Este é o diretório de usuários como ele aparece quando você o abre. Período semanal, ordenado por curtidas recebidas. Agora mudo a ordem para Posts lidos:

Em seguida, mudo o período para hoje:

E o mesmo (hoje, ordenado por posts lidos) após uma recarga

Como você pode ver, o número de posts que @lcor leu hoje mudou após a recarga. Antes, não se encaixava na lista ordenada.
Na verdade, os 214 são os posts lidos esta semana:

Esta não foi a única conta onde os números mostraram a contagem semanal em vez da de hoje quando realizei essas etapas. Há mais usuários que parecem não estar no lugar certo, onde na verdade os números semanais estão sendo exibidos.

Próximos usuários na lista antes/depois da recarga

Você acha que é o mesmo problema ou coincidentemente existem 2 problemas agora?

[Moin]

Ainda consigo reproduzir isso com os passos acima. Por exemplo, as estatísticas de thoka estão incorretas antes da recarga:

E corretas após a recarga:

[zogstrip]

Consigo reproduzir aqui no meta

Antes da atualização

Depois da atualização

Os números são de fato diferentes, mas o mais importante é que estamos sempre fazendo duas requisições para o endpoint directory_items (uma com e outra sem a extensão .json), mas uma delas tem parâmetros incorretos

No entanto, não consigo reproduzir localmente. Tenho duas requisições diferentes, mas elas são para endpoints diferentes (groups/search.json vs directory_items).

–

EDIT: habilitar o componente de tema user card directory não altera o problema/comportamento.

[Moin]

Você tentou adicionar mais usuários à sua instalação local? Eu me pergunto se você precisa de mais de 50 usuários, para que nem todos sejam carregados de uma vez.
Acho que os usuários que mostram números errados foram aqueles que não estavam visíveis no primeiro carregamento.

[zogstrip]

Tentei armazenar alguns dados em cache localmente para que não façamos solicitações desnecessárias a cada alteração na ordem/coluna de classificação

PERF: cache requests when navigating user directory

Mas não tenho certeza se isso corrigirá a solicitação dupla / condição de corrida que está acontecendo em produção, pois não consegui reproduzir localmente

[zogstrip]

Hmmm, isso não corrigiu o problema da solicitação dupla e agora estou vendo um erro de JS com “loadMore” sendo chamado em undefined

[zogstrip]

Isso acabou sendo uma condição de corrida desagradável entre o “sentinela” que usamos para detectar quando precisamos acionar a ação “carregar mais” e a renderização das linhas no diretório de usuários

O Problema

Quando havia pelo menos 50 usuários, a página /u (diretório de usuários) acionava loadMore imediatamente no primeiro carregamento, antes que o usuário pudesse rolar para baixo. Isso causou o carregamento automático de uma segunda página de resultados indesejada.

Causa Raiz

Condição de corrida de tempo durante o carregamento inicial da página:

1. Usuário navega para /u
2. controllers/users começa a carregar dados (isLoading: true)
3. O template renderiza com ConditionalLoadingSpinner mostrando o spinner
4. Os dados chegam, isLoading se torna false
5. O spinner é ocultado, DirectoryTable começa a renderizar 50 usuários
6. O sentinela LoadMore é inserido no DOM
7. IntersectionObserver é criado e começa a observar imediatamente
8. Neste momento, a tabela ainda está calculando o layout/expandindo para a altura total
9. O sentinela fica brevemente visível na viewport (~292px do topo) antes da tabela expandir
10. O observador detecta a interseção → aciona loadMore
11. A tabela termina de expandir para a altura total (~3689px)
12. O sentinela se move para a posição correta (~3959px, abaixo da viewport)

O observador foi “muito ansioso” - ele começou a observar antes que o conteúdo terminasse seu layout, capturando o sentinela durante o breve momento em que a tabela ainda não havia atingido sua altura final.

A Correção

Atrasar a criação do observador até que o conteúdo esteja pronto:

Adicionado um parâmetro @isLoading a LoadMore que impede a criação do IntersectionObserver quando o conteúdo ainda está carregando.

Como Funciona Agora

Carregamento da página → isLoading=true → Modifier pula a criação do observador
             ↓
Carregamento dos dados → isLoading=false → Modifier executa novamente, cria o observador
             ↓
Tabela totalmente expandida → Sentinela na posição correta (abaixo da viewport)
             ↓
Usuário rola para baixo → Sentinela entra na viewport → loadMore é acionado ✓

---

FIX: eager "load more" in users directory