React-window: سيؤدي تغيير الدعائم لعنصر واحد إلى تحديث القائمة بأكملها

لدي نفس حالة الاستخدام والمشكلة بالضبط ، ولم أتمكن من إيجاد حل ...

هذا لأن تغيير عنصر يؤدي إلى إنشاء مصفوفة items جديدة مما

إذا كنت تريد أن تكون العناصر أكثر قوة لهذا النوع من التغيير ، فيمكنك تنفيذ وظيفة areEqual الخاصة بك (أو shouldComponentUpdate ).

الغرض من العرض التوضيحي هو إظهار كيف يمكن أن يعمل itemData و memoization معًا لتمرير القيم المعقدة.

لقد اختبرت ذلك باستخدام وظيفة shouldComponentUpdate الخاصة بي ولكن لن يتم تنفيذ هذه الوظيفة ، إذا تم إلغاء تحميل المكون مرارًا وتكرارًا

إذا تم تحميل المكون مرارًا وتكرارًا

لا توجد طريقة لإحياء ذكرى أحد المكونات التي يتم فك تركيبها. هذا ليس ما يحدث في العرض التوضيحي الخاص بي. إذا كان هذا هو ما يحدث في تطبيقك ، فهناك شيء آخر يحدث - ولا يمكنني التكهن بما يحدث.

BertelBB هل وجدت حلاً؟

ffjanhoeck ليس حقًا ، لا. لقد أدركت أن حالة الاستخدام الخاصة بي مختلفة قليلاً في الواقع ، بمعنى أنه يمكن أيضًا فرز / تصفية قائمتي. ما فعلته هو تمرير عناصر itemData و itemKey حتى أقوم يدويًا بتعيين
https://react-window.now.sh/#/api/FixedSizeList هنا يمكنك أن تقرأ عن الدعائم التي أشير إليها.

BertelBB لقد قمت بالفعل بتنفيذ هذه الوظيفة بالأمس ، شكرًا لك :)
لكن المشكلة لم يتم حلها :(
فيما يلي صورة GIF بطيئة - كما ترون ، فقد استغرق الأمر بعض المللي ثانية للتحقق من عنصر.
يتم حفظ كل شيء في الذاكرة أو يتم تطبيقه shouldComponentUpdate.

ffjanhoeck نعم ، لدي نفس المشكلة. للأسف ليس لدي الوقت للنظر في هذا الأمر حتى الآن. لكنني سأخبرك إذا وجدت حلاً أفضل :)

ffjanhoeck هل يمكنني إلقاء نظرة على التطبيق الذي عرضته في GIF أعلاه؟ سأكون فضوليًا لتشغيل ملف تعريف ومعرفة من أين يأتي البطء.

bvaughn نعم بالتأكيد - لقد أرسلت لك بيانات الاعتماد على بريدك الإلكتروني! :)

أعتقد أن البطء يأتي من المعاينة القصيرة لعنصر ما (تمثل الصورة والنص الأزرق مع النص الثانوي مكون EntityShortPreview). لكنها ليست مشكلة لعنصر واحد. تكمن المشكلة في أن جميع العناصر يتم فكها وتثبيتها على التحديد وإذا لخصت ذلك ، فهذا يعني أنه بطيء.

هذا هو شعوري الحالي: D ولكن ربما يمكنك العثور على بعض المشكلات الأخرى :)

يحدث هذا إذا اختار المستخدم عنصرًا واحدًا

ffjanhoeck واجهت نفس المشكلة بالضبط ، وبعد بعض التحقيقات ، تمكنت من معرفة السبب: هذا لأننا نستخدم وظائف مجهولة كعارضين للعناصر ، بدلاً من المكونات المسماة. أنا لست خبيرًا في React ، لكنني أعتقد أن هذا يفسد تسوية React ، نظرًا لأن المكونات لا يمكن التعرف عليها كما هي بين عمليات العرض.

قمت بعمل مثال CodeSandbox يوضح المشكلة هنا: https://codesandbox.io/s/qx4088mn36

أعتقد أن هذا مرتبط أيضًا بالمحادثة هنا: https://github.com/bvaughn/react-window/issues/85#issuecomment -436329610

هذا ما أراه أيضًا بعد نظرة سريعة هذا الصباح. (كنت أكتب بريدًا إلكترونيًا ولكن تمت مقاطعته.) أدى نقل الوظيفة المضمنة إلى دعامة مثيل إلى تسريع الأمور ، (ولكن أيضًا كسر بعض الأشياء الأخرى التي لم يكن لدي وقت لتعقبها نظرًا لحجم حالة repro).

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

هذا صحيح. 👍

همم. هذا أمر مؤسف ، لأنني أكتب مشروعي باستخدام ReasonReact ، والذي (حاليًا) يفتقر إلى الدعائم اللازمة لنشر / ميزات المكون الوظيفي لتجنب هذه المشكلة. أدرك أن هذه ليست بأي حال من الأحوال مشكلة في نافذة التفاعل ، إنها مجرد قيود على نظام نوع ReasonML ، لكنني أفترض أنه من الجدير بالذكر في حالة تعثر أي شخص آخر في هذا الموضوع.

للتوضيح ، هذا هو السبب في أن جميع أمثلة المستندات توضح أن عرض العنصر يتم تعريفه خارج المكون الرئيسي ،

رائع ، سوف ألقي نظرة! :)

حلك حل المشكلة! شكرا وأتمنى لك يوم سعيد