ユーザーディレクトリのユーザー統計情報が正しくありません

[Moin]

そのブランチに基づいて構築されたCodespaceで再現できたと思います。

今日、ユーザーディレクトリの数字が間違っていることがあり、ユーザーがロードされていない問題が原因かもしれないと思ったので試してみました。

私が気づいた間違った数字の例：

これは、開いたときのユーザーディレクトリの外観です。タイムスパンは週次で、受け取ったいいねの数で並べ替えられています。次に、投稿の閲覧数で並べ替えます。

次に、タイムスパンを今日に変更します。

そして、リロード後の同じ（今日、投稿の閲覧数で並べ替えられた）状態：

ご覧のとおり、リロード後に @lcor が今日読んだ投稿の数が変わりました。以前は、並べ替えられたリストに収まりませんでした。
実際、214 は今週読まれた投稿数です。

これらの手順を実行したときに、今日ではなく週次のカウントが表示されているように見えるユーザーが他にもいるなど、数字が週次のカウントを示していたのは、このアカウントだけではありませんでした。週次の数字が表示されている、本来あるべき場所にないように見えるユーザーが他にもいます。

リロード前/後のリストの次のユーザー

これは同じ問題だと思いますか、それとも偶然にも現在2つの問題がありますか？

[Moin]

上記の手順で、これも再現できます。たとえば、リロードする前のトーカのステータスは間違っています。

リロード後の正しいステータスは次のとおりです。

[zogstrip]

ここでメタで再現できます。

リフレッシュ前

リフレッシュ後

数字は確かに異なりますが、さらに重要なのは、常に directory_items エンドポイントに2つのリクエストを行っている（1つは .json 拡張子あり、もう1つはなし）のに、そのうちの1つが間違ったパラメータを持っていることです

しかし、ローカルでは再現できません。2つの異なるリクエストがありますが、それらは異なるエンドポイント（groups/search.json vs directory_items）に対して行われています。

–

編集：ユーザーカードディレクトリテーマコンポーネントを有効にしても、問題/動作は変わりません。

[Moin]

ローカルインストールにユーザーをさらに追加してみましたか？一度にすべてを読み込まないように、50人以上のユーザーが必要なのではないかと思います。

表示される数値が間違っていたユーザーは、最初に読み込まれたときに表示されていなかったユーザーだったのではないでしょうか。

[zogstrip]

ローカルにデータをキャッシュするように試みました。これにより、ソート順序や列の変更ごとに不要なリクエストを行うことがなくなります。

PERF: cache requests when navigating user directory

しかし、本番環境で発生している二重リクエスト/競合状態をローカルで再現できなかったため、これが修正されるかはわかりません

[zogstrip]

うーん、これで二重リクエストの問題は解決せず、「loadMore」が undefined で呼び出されるというJSエラーが表示されるようになりました

[zogstrip]

これは、ユーザーディレクトリの行のレンダリングと、「さらに読み込む」アクションをトリガーする必要があるかどうかを検出するために使用する「センチネル」との間の、厄介な「競合状態」になりました

問題点

ユーザーが少なくとも50人いる場合、「/u」（ユーザーディレクトリ）ページは、ユーザーがスクロールする前に、最初の読み込み時にすぐに loadMore をトリガーしていました。これにより、意図しない2ページ目の結果が自動的に読み込まれていました。

原因

初期ページ読み込み中のタイミング競合状態:

1. ユーザーが /u に移動します
2. controllers/users がデータの読み込みを開始します (isLoading: true)
3. テンプレートが ConditionalLoadingSpinner を表示してレンダリングされます
4. データが到着し、isLoading が false になります
5. スピナーが非表示になり、DirectoryTable が50人のユーザーのレンダリングを開始します
6. LoadMore センチネル要素が DOM に挿入されます
7. IntersectionObserver が作成され、すぐに監視を開始します
8. この時点で、テーブルはまだレイアウトを計算中/完全な高さに展開中です
9. テーブルが展開する前の短い時間（上から約292px）でセンチネルが表示されます
10. オブザーバーが交差を検出 → loadMore をトリガーします
11. テーブルが完全な高さ（約3689px）まで展開を完了します
12. センチネルが正しい位置（ビューポートの下、約3959px）に移動します

オブザーバーが「性急」すぎました。コンテンツのレイアウトが完了する前に監視を開始し、テーブルが最終的な高さに達する前の短い瞬間にセンチネルを捉えてしまいました。

修正

コンテンツが準備できるまでオブザーバーの作成を遅延させる:

LoadMore に @isLoading パラメータを追加し、コンテンツがまだ読み込み中の場合に IntersectionObserver が作成されないようにしました。

現在の動作

ページ読み込み → isLoading=true → Modifier はオブザーバー作成をスキップします
             ↓
データ読み込み → isLoading=false → Modifier が再実行され、オブザーバーが作成されます
             ↓
テーブルが完全に展開 → センチネルが正しい位置（ビューポートの下）にあります
             ↓
ユーザーが下にスクロール → センチネルがビューポートに入る → loadMore がトリガーされます ✓

---

FIX: eager "load more" in users directory