प्रोडक्ट चाहता है कि पचास हज़ार rows की table sorting और inline editing के साथ दिखे। आप इसे कैसे बनाएंगे?

पचास हज़ार rows को DOM में मत डालिए। virtualize कीजिए ताकि सिर्फ दिखने वाली खिड़की और थोड़ा overscan render हो, row की ऊंचाई अंदाज़े लायक रखिए या नापिए, और sorting तथा filtering को render से निकालकर memoized derived डेटा या सर्वर पर ले जाइए। डेटा को खुद paginate या stream कीजिए, edit हो रही row की state local रखिए ताकि हर keystroke पूरी table दोबारा render न करे, और throttled CPU पर जांचिए।

पहली बात मैं यह कहता हूं कि पचास हज़ार rows एक साथ DOM में कभी नहीं होनी चाहिए, क्योंकि layout और memory nodes की गिनती के साथ बढ़ते हैं, चाहे मेरा framework कितना ही तेज़ हो। तो मैं virtualize करता हूं: viewport की rows और थोड़ा overscan render करो, उन्हें कुल ऊंचाई वाले spacer के अंदर absolutely position करो, और scroll के साथ उन्हें दोबारा इस्तेमाल करो। फिर मैं डेटा को अलग समस्या मानता हूं। हर keystroke पर पचास हज़ार records की sorting और filtering main thread रोक देगी, तो या तो सर्वर वह करे और मैं एक पेज मांगूं, या मैं derived array को memoize करूं ताकि वह तभी दोबारा बने जब sort key सच में बदले। inline editing के लिए मैं draft value उसी row की अपनी state में रखता हूं और commit पर ही ऊपर उठाता हूं, वरना हर अक्षर पर पूरी table दोबारा render होती है। जो हिस्से लोग भूल जाते हैं वे हैं एक्सेसिबिलिटी और पेज में खोज: screen readers और ब्राउज़र की search सिर्फ render हुई rows देखती हैं, तो मैं row की गिनती वाले attributes साफ साफ सेट करता हूं और ब्राउज़र वाली पर भरोसा करने की जगह एक असली search box देता हूं।