لدي سؤال بخصوص التمرير: على نظام أندرويد، هناك شيء يسمى recyclerview إنشاء قوائم ديناميكية باستخدام RecyclerView | مطورو Android يعيد استخدام المكونات بدلاً من إضافة المزيد والمزيد أثناء التمرير. يبدو أن discourse لا يفعل ذلك؟ لماذا؟ هل هناك استراتيجية مختلفة مستخدمة؟ لدي فكرة غامضة بأن نظام vdom widget المخصص تم إنشاؤه لمعالجة هذه المشكلة (قائمة متزايدة باستمرار من عناصر DOM) ولكن بصراحة، لا أزال لا أفهم كيف يحل ذلك المشكلة. 
ربما يمكن لشخص ما أن يلقي بعض الضوء على ذلك 
3 إعجابات
نحن نحمل 20 منشورًا فقط في كل مرة، باستخدام ما يسمى “التمرير الافتراضي”.
4 إعجابات
ماذا يحدث لعناصر DOM القديمة؟ إذا واصلت التمرير، أتخيل أنه سيتم إضافة المزيد والمزيد من العناصر إلى شجرة DOM. هل يتم إزالتها في مرحلة ما؟
إعجاب واحد (1)
لا، نتركها موجودة، لدينا جزء منطقي “مموه” يستبدل العناصر بعنصر نائب بمجرد أن تكون بعيدًا جدًا عن منفذ العرض، ثم عندما تقترب من العنصر، نقوم بإلغاء التمويه عن طريق إعادة التصيير. الحد الخاص بهذه الحيلة مرتفع جدًا.
4 إعجابات
@sam هل هناك مقال يمكنك ربطه بي يقارن هذه التقنية بإعادة تدوير المكونات؟ سأكون مهتمًا بقراءة المزيد عنها. كيف اتخذت هذا القرار؟ أتخيل أن A tour of how the Widget (Virtual DOM) code in Discourse works يتعلق بهذا أيضًا.
إعجاب واحد (1)
لا أعتقد أن لدينا مقالًا، ولكن ربما أكون مخطئًا. ربما يتذكر @eviltrout ما إذا كنا قد وثقنا بعض قراراتنا بشأن إخفاء ما بعد الإنتاج. لست متأكدًا.
إعجابَين (2)
لقد مر وقت طويل جدًا لدرجة أنني لا أتذكر، للأسف.
لا أعتقد أننا قمنا بتحليل مكونات إعادة التدوير بالكامل. كان الإخفاء انتصارًا كبيرًا وحل مشاكلنا في ذلك الوقت.
4 إعجابات
@eviltrout رأيت هذا المنشور Evil Trout Inc.
بعد سنوات من انتظار اختراق في أداء Android أو Ember، قررنا أنه حان الوقت لاتخاذ الخيار النووي: استبدلنا محرك عرض Ember لأكثر طرق العرض شيوعًا لدينا بعارض مخصص يعتمد على DOM الافتراضي.
لذا يبدو أن نظام vdom/widget في discourse تم بناؤه استجابة لمشاكل أداء Android.
يبدو أن هذا الالتزام الذي يقدم التمويه يحدث بعد نظام vdom/widget:
هل التمويه ونظام vdom/widget مرتبطان ببعضهما البعض بطريقة ما؟ يبدو أنهما يعالجان الأداء. إعادة تدوير المكونات من شأنها أن تقلل بشكل كبير من عدد عناصر DOM، لذلك لن يكون هناك حاجة لشيء مثل نظام vdom/widget، أليس كذلك؟
إعجابَين (2)
كان لدينا الإخفاء قبل vdom، ولكن تم إعادة تنفيذه بعد أن لاحظنا أننا بحاجة إليه هناك أيضًا.
يجب أن يؤدي إعادة تدوير المكونات إلى تقليل الذاكرة وتحسين الأمور في الموضوعات الكبيرة، ولكنه لن يسرع وقت العرض الذي تقوم به الأدوات المساعدة بشكل كبير.
3 إعجابات
لا يمكن التقليل من شأن حقيقة أن جميع مشكلات الأداء تتعلق بالمقايضات. أعتقد أن Ember يفعل الشيء الصحيح هنا ويركز على التطبيقات المنظمة وتتوسع مع إضافة المزيد من الميزات. بالنسبة لغالبية طرق العرض في تطبيقك، لن يقلقك عبء عمل الإطار. ومع ذلك، إذا كنت تقوم بعرض العديد من المكونات المتداخلة مع العديد من الارتباطات، يمكن أن يصبح الوضع مرضيًا.
بينما قد تبدو Discourse بسيطة على السطح، يتم عرض كل مشاركة باستخدام عدد قليل من المكونات. لدينا العديد من الأزرار الديناميكية والروابط والتأثيرات المطبقة في كل مرة يتم فيها عرض مشاركة مع أكثر من 150 سمة متضمنة.
رأيت هذا في تدوينة كتبها @eviltrout. يبدو أن أداء Ember ليس مشكلة بشكل عام، ولكن فقط في الحالة المحددة لمواضيع Discourse، أليس كذلك؟ مواضيع Discourse هي قائمة طويلة جدًا من المكونات (المشاركات) التي تحتوي على الكثير من المكونات بداخلها (زر الرد، زر الإعجاب، إلخ). هذا ما يؤدي إلى تدهور أداء العرض.
تخفف vdom/widgets هذه المشكلة إلى حد ما، لأنها تجعل عملية العرض أقل تكلفة. ولكن في مرحلة ما، يصبح عدد عناصر DOM كبيرًا جدًا لدرجة أنه يجب تقليلها عن طريق إخفائها.
إعادة تدوير المكونات يعني تجنب هذه المشكلة تمامًا، عن طريق وجود عدد ثابت فقط من عناصر DOM على الشاشة، والتي يتم إعادة استخدامها عندما يقوم المستخدم بالتمرير عبر المحتوى.
يرجى تصحيحي إذا كنت قد وصفت أي شيء بشكل خاطئ.
شكرًا،
سبيرو بيل 
إعجابَين (2)