إحصائيات المستخدم غير صحيحة في دليل المستخدم

أعتقد أنني تمكنت من إعادة إنتاجه في Codespace مبني على هذا الفرع.

لقد حاولت لأنني لاحظت اليوم أن الأرقام في دليل المستخدم خاطئة أحيانًا واعتقدت أن ذلك قد يكون بسبب مشكلة عدم تحميل المستخدمين.

مثال على الأرقام الخاطئة التي لاحظتها:


هذا هو دليل المستخدم كما يبدو عند فتحه. النطاق الزمني أسبوعي، مرتب حسب الإعجابات المستلمة. الآن أقوم بتغيير الترتيب إلى “المشاركات المقروءة”:

ثم أقوم بتغيير النطاق الزمني إلى “اليوم”:

ونفس الشيء (اليوم، مرتب حسب المشاركات المقروءة) بعد إعادة تحميل:

كما ترى، تغير عدد المشاركات التي قرأها @lcor اليوم بعد إعادة التحميل. من قبل، لم يكن يتناسب مع القائمة المرتبة.
في الواقع، الـ 214 هي المشاركات التي تمت قراءتها هذا الأسبوع:


لم يكن هذا هو الحساب الوحيد الذي أظهرت فيه الأرقام العدد الأسبوعي بدلاً من عدد اليوم عند قيامي بهذه الخطوات. هناك المزيد من المستخدمين الذين يبدون وكأنهم ليسوا في المكان الصحيح، حيث يتم عرض الأرقام الأسبوعية بالفعل.

المستخدمون التاليون في القائمة قبل/بعد إعادة التحميل

هل تعتقد أن هذه هي نفس المشكلة أم أن هناك مشكلتين متزامنتين الآن؟

4 إعجابات

لا يزال بإمكاني تكرار هذا باستخدام الخطوات المذكورة أعلاه. على سبيل المثال، إحصائيات thoka غير صحيحة قبل إعادة التحميل:

وصحيحة بعد إعادة التحميل:

أنا قادر على إعادة إنتاج ذلك هنا على ميتا

قبل التحديث

بعد التحديث

الأرقام مختلفة بالفعل ولكن الأهم من ذلك هو أننا نقوم دائمًا بطلبين لنقطة النهاية directory_items (واحد مع، والآخر بدون الامتداد .json) ولكن أحدها يحتوي على معلمات غير صحيحة :thinking:

ومع ذلك، لا يمكنني إعادة إنتاج ذلك محليًا، لدي طلبان مختلفان، ولكنهما على نقاط نهاية مختلفة (groups/search.json مقابل directory_items)

تعديل: تمكين مكون سمة دليل بطاقات المستخدم لا يغير المشكلة/السلوك.

هل حاولت إضافة المزيد من المستخدمين إلى تثبيتك المحلي؟ أتساءل عما إذا كنت بحاجة إلى أكثر من 50 مستخدمًا، بحيث لا يتم تحميلهم جميعًا دفعة واحدة. أعتقد أن المستخدمين الذين تظهر لديهم أرقام خاطئة هم أولئك الذين لم يكونوا مرئيين عند التحميل الأولي.

لقد حاولت تخزين بعض البيانات محليًا حتى لا نقوم بطلبات غير ضرورية عند كل تغيير في ترتيب الفرز/العمود

لكنني لست متأكدًا من أن هذا سيصلح الطلب المزدوج/حالة السباق التي تحدث في بيئة الإنتاج حيث لم أتمكن من إعادة إنتاجها محليًا :frowning:

إعجابَين (2)

حسنًا، لم يحل هذا مشكلة الطلب المزدوج والآن أرى خطأ في جافاسكريبت مع استدعاء “loadMore” على undefined :thinking:

إعجاب واحد (1)

إذًا، انتهى بنا الأمر إلى حالة “سباق” سيئة بين “الحارس” الذي نستخدمه لاكتشاف متى نحتاج إلى تشغيل إجراء “تحميل المزيد” وعرض الصفوف في دليل المستخدمين :exploding_head:

المشكلة

عندما كان هناك 50 مستخدمًا على الأقل، كانت صفحة /u (دليل المستخدمين) تشغل loadMore فورًا عند التحميل الأول، قبل أن يتمكن المستخدم من التمرير لأسفل. تسبب هذا في تحميل صفحة ثانية غير مرغوب فيها من النتائج تلقائيًا.

السبب الجذري

حالة سباق توقيت أثناء تحميل الصفحة الأولي:

  1. ينتقل المستخدم إلى /u
  2. يبدأ controllers/users في تحميل البيانات (isLoading: true)
  3. يتم عرض القالب مع ConditionalLoadingSpinner الذي يعرض الدوار
  4. تصل البيانات، وتصبح isLoading false
  5. يختفي الدوار، ويبدأ DirectoryTable في عرض 50 مستخدمًا
  6. يتم إدراج عنصر الحارس LoadMore في DOM
  7. يتم إنشاء IntersectionObserver ويبدأ في المراقبة فورًا
  8. في هذه اللحظة، لا يزال الجدول يحسب التخطيط/يتوسع إلى الارتفاع الكامل
  9. يظهر الحارس لفترة وجيزة في منفذ العرض (~292 بكسل من الأعلى) قبل أن يتوسع الجدول
  10. يكتشف المراقب التقاطع → يشغل loadMore :cross_mark:
  11. يكمل الجدول التوسع إلى الارتفاع الكامل (~3689 بكسل)
  12. ينتقل الحارس إلى الموضع الصحيح (~3959 بكسل، أسفل منفذ العرض)

كان المراقب “متسرعًا جدًا” - بدأ المراقبة قبل انتهاء المحتوى من تخطيطه، والتقط الحارس خلال اللحظة القصيرة عندما لم يصل الجدول إلى ارتفاعه النهائي بعد.

الإصلاح

تأخير إنشاء المراقب حتى يصبح المحتوى جاهزًا:

تمت إضافة معلمة @isLoading إلى LoadMore تمنع إنشاء IntersectionObserver عندما لا يزال المحتوى قيد التحميل.

كيف يعمل الآن

تحميل الصفحة → isLoading=true → يتخطى المعدل إنشاء المراقب
             ↓
تحميل البيانات → isLoading=false → يعيد المعدل التشغيل، وينشئ المراقب
             ↓
الجدول متوسع بالكامل → الحارس في الموضع الصحيح (أسفل منفذ العرض)
             ↓
يقوم المستخدم بالتمرير لأسفل → يدخل الحارس منفذ العرض → يتم تشغيل loadMore ✓

5 إعجابات

تم إغلاق هذا الموضوع تلقائيًا بعد 15 ساعة. لم يعد يُسمح بالردود الجديدة.