Moin
1
我似乎能够在基于该分支构建的 Codespace 中重现它。
我尝试这样做是因为今天我注意到用户目录中的数字有时是错误的，我想这可能是因为用户未加载的问题。
我注意到的错误数字示例：
这是打开用户目录时它的样子。时间范围是每周，按收到的喜欢次数排序。现在我将顺序更改为阅读的帖子：
然后我将时间范围更改为今天：
刷新后，同样（今天，按阅读帖子数排序）：
正如你所看到的，@lcor 今天阅读的帖子数量在刷新后发生了变化。之前，它不适合排序列表。
实际上，214 是本周阅读的帖子：
当我执行这些步骤时，这并不是唯一一个数字显示本周计数而不是今天的计数帐户。还有更多用户看起来不在正确的位置，实际上显示的是每周的数字。
刷新前后列表中的下一个用户
你认为这是同一个问题，还是碰巧现在有两个问题？
4 个赞
Moin
2
我仍然可以重现此问题，方法如上所述。例如，在重新加载之前，thoka 的统计数据是错误的：
重新加载后则正确：
我可以在这里重现\n\n刷新前\n
\n\n
刷新后\n
\n\n数字确实不同，但更重要的是，我们总是向
directory_items 端点发出两个请求（一个带
.json 扩展名，一个不带），但其中一个请求的参数不正确
\n\n不过我无法在本地重现，我有两个不同的请求，但它们在不同的端点（
groups/search.json vs
directory_items）\n\n
\n\n–\n\n编辑：启用
user card directory 主题组件不会改变问题/行为。
Moin
5
您是否尝试过在本地安装中添加更多用户？我想知道您是否需要超过 50 个用户，以便并非所有用户都能一次性加载。
我认为显示错误数字的用户是在首次加载时不可见的用户。
我尝试将一些数据本地缓存起来，这样在每次更改排序顺序/列时就不会发出不必要的请求
但我不知道这是否能解决生产环境中发生的双重请求/竞态条件问题，因为我无法在本地重现 
2 个赞
嗯，这并没有解决双重请求问题，而且我现在看到一个 JavaScript 错误，提示在 undefined 上调用了“loadMore”
1 个赞
这最终变成了一个棘手的“竞态条件”，发生在用于检测何时需要触发“加载更多”操作的“哨兵”与用户目录中行的渲染之间 
问题
当用户数量至少为 50 时，“/u”（用户目录）页面会在用户向下滚动之前立即触发 loadMore。这会导致意外地自动加载第二页结果。
根本原因
初始页面加载期间的竞态条件：
- 用户导航到
/u
controllers/users 开始加载数据 (isLoading: true)- 模板渲染
ConditionalLoadingSpinner 并显示加载指示器
- 数据到达，
isLoading 变为 false
- 加载指示器隐藏，
DirectoryTable 开始渲染 50 个用户
LoadMore 哨兵元素插入 DOMIntersectionObserver 被创建并立即开始观察- 此时，表格仍在计算布局/扩展到完整高度
- 在表格扩展之前，哨兵短暂地出现在视口中（距离顶部约 292px）
- 观察者检测到交叉 → 触发
loadMore 
- 表格完成扩展到完整高度（约 3689px）
- 哨兵移动到正确位置（约 3959px，视口下方）
观察者“过于积极”——它在内容完成布局之前就开始观察，在表格尚未达到最终高度的短暂时刻捕获了哨兵。
修复
延迟创建观察者，直到内容准备就绪：
向 LoadMore 添加了一个 @isLoading 参数，当内容仍在加载时，该参数会阻止创建 IntersectionObserver。
现在的工作方式
页面加载 → isLoading=true → Modifier 跳过观察者创建
↓
数据加载 → isLoading=false → Modifier 重新运行，创建观察者
↓
表格完全展开 → 哨兵位于正确位置（视口下方）
↓
用户向下滚动 → 哨兵进入视口 → loadMore 触发 ✓
5 个赞
