مشكلة عرض القوائم الكبيرة

افترضوا أنكم تمرّرون على مصفوفة تضم عشرة آلاف عنصر وتصيّرون عنصر li لكل واحد منها. سيُنشئ React عشرة آلاف عقدة DOM دون تردّد، رغم أن بضع عشرات منها فقط تتسع لها الشاشة في الوقت نفسه.

تكون معظم هذه العقد خارج الشاشة وغير مرئية، ومع ذلك يجب على المتصفح إنشاء كل واحدة منها وتخطيطها وصيانتها.

يتحمّل المتصفح تكلفة فعلية عند التعامل مع أشجار DOM الكبيرة. إذ يزداد كل من التخطيط وإعادة حساب الأنماط واستهلاك الذاكرة مع زيادة عدد العقد، لذلك تؤدي القائمة الضخمة إلى إبطاء التصيير الأولي وزيادة استخدام الذاكرة.

حتى التفاعلات البسيطة قد تتقطّع عندما يتعين على المحرك تتبّع عشرات الآلاف من العقد وإعادة تخطيطها.

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

والنتيجة هي تمرير متقطّع وبطيء يجعل الواجهة تبدو غير مستجيبة، مهما كانت سرعة بقية التطبيق.

يمكنكم تأكيد المشكلة من خلال لوحة Memory في DevTools بالمتصفح، التي تعرض عدد عقد DOM الموجودة في الصفحة. وستظهر هنا بوضوح القائمة التي تنشئ آلاف العقد.

إن مراقبة تضخّم هذا العدد مع تصيير مزيد من العناصر تمنحكم دليلًا ملموسًا على أن حجم DOM هو عنق الزجاجة.

تقوم المحاكاة الافتراضية، التي تُسمّى أحيانًا windowing، بتصيير العناصر المرئية حاليًا فقط مع مخزن مؤقت صغير، بدلًا من تصيير القائمة بأكملها. ومع التمرير، تُثبَّت العناصر التي تدخل إلى نطاق العرض وتُزال العناصر التي تخرج منه.

يحافظ هذا على صِغر حجم DOM الفعّال مهما كان عدد العناصر في البيانات، ويفصل حجم DOM عن حجم مجموعة البيانات.

تُشتق النافذة المرئية من موضع التمرير وارتفاع الحاوية وارتفاع العنصر. ويعطي قسْم ارتفاع منفذ العرض على ارتفاع العنصر عددًا تقريبيًا للصفوف التي تتسع لها الشاشة، بينما يحدد إزاحة التمرير الصفوف المقصودة.

تستخدم المكتبة هذه الأرقام لتحديد شريحة العناصر التي ينبغي تصييرها بدقة في كل لحظة.

تطبّق عدة مكتبات تقنية windowing. تتميز react-virtualized بكثرة الميزات لكنها أكبر حجمًا، بينما تمثل react-window إعادة كتابة أصغر وأكثر تركيزًا من المؤلف نفسه، وتوفر TanStack Virtual خيارًا حديثًا بلا واجهة مفروضة.

بالنسبة إلى معظم القوائم، توفر react-window توازنًا ممتازًا بين البساطة والأداء، ولهذا تركز هذه الدورة عليها.

تكون المحاكاة الافتراضية مفيدة عندما تكون القوائم طويلة، أي تضم عادةً عدة مئات من الصفوف أو أكثر، أو عندما تكون الصفوف غنية بالصور والمكوّنات المتداخلة. ففي هذه الحالات يؤثر حجم DOM فعلًا في الأداء.

تُعد الخلاصات اللانهائية وجداول البيانات الكبيرة وسجلّات المحادثات أمثلة شائعة على الحالات التي تصبح فيها تقنية windowing ضرورية لا اختيارية.

بالنسبة إلى القوائم القصيرة التي تضم بضع عشرات من العناصر البسيطة، تضيف المحاكاة الافتراضية تعقيدًا من دون فائدة ملموسة. بل إن تكلفة تحديد المواضع المطلقة وقياس العناصر قد تجعل المحصلة سلبية.

احجزوا تقنية windowing لمجموعات البيانات الكبيرة فعلًا؛ أما في المجموعات الصغيرة، فستكون map العادية أبسط وسريعة بما يكفي.

مع استخدام windowing، لا تحتفظ قائمة تضم مئة ألف عنصر في DOM إلا بعدد قليل من العناصر المرئية، لذلك يكون التصيير الأولي سريعًا وتبقى الذاكرة منخفضة ويظل التمرير سلسًا.

أنتم تستبدلون قدرًا بسيطًا من التعقيد في الإعداد بأداء لم يعد يعتمد على كمية البيانات لديكم، وهذا هو الوعد الأساسي للمحاكاة الافتراضية.

حدّدوا متى تكون المحاكاة الافتراضية جديرة بالاستخدام.

يؤدي تصيير آلاف عقد DOM إلى زيادة تكلفة التخطيط واستهلاك الذاكرة وتقطّع التمرير، ويمكنكم تأكيد ذلك من خلال عدد العقد في DevTools. أما المحاكاة الافتراضية فتصيّر النافذة المرئية مع مخزن مؤقت، وتحافظ على صِغر حجم DOM.

تُعد react-window خيارًا متخصصًا وخفيفًا مقارنةً بـ react-virtualized وTanStack Virtual. استخدموها للقوائم الكبيرة أو الثقيلة، وتجاوزوها في القوائم القصيرة والبسيطة.