🤛🏾 🕙 🌝 कुछ चरणों में MatTable प्रतिपादन की गति 🧀 🦈 🙌🏼

अक्सर ऐसा होता है कि अधिकांश एप्लिकेशन विभिन्न सूचियों और तालिकाओं से बने होते हैं। हर बार पहिया को सुदृढ़ नहीं करने के लिए, मैं, जैसे कई, अक्सर उपयोग किया जाता है कोणीय सामग्री तालिकाओं ।

बाद में, ये तालिकाओं में वृद्धि हुई, दोनों पाठ डेटा और नेस्टेड तत्वों को कोशिकाओं में रखा गया। यह सब बढ़ता है और उपयोगकर्ता की मशीन पर एक अच्छा भार बन जाता है। और हां, किसी को भी यह पसंद नहीं है।

मेरी अंतिम होम परियोजना में, एक तालिका थी, जिसकी कोशिकाएँ अधिकतर विभिन्न क्षेत्रों से भरी हुई थीं (आप यह भी कह सकते हैं कि यह एक बड़ा रूप था)।

और इसे रेंडर करने में लगभग 8 सेकंड (40 x 40 टेबल) लगे।

तो आप बड़ी सूची के लिए मैटटेबल को कैसे अनुकूलित कर सकते हैं?

परीक्षण का मामला

इस समस्या से निपटने में दूसरों की मदद करने के लिए, मैंने एक छोटा परीक्षण आवेदन लिखा। सभी एक ही MatTable तालिका, जिसमें पांच कॉलम होते हैं (पहला तत्व की आईडी है, बाकी नियमित MatFormField टेक्स्ट हैं)।

ऐसा लगता है कि यह एक साधारण तालिका है, लेकिन यहां तक कि इस तरह की एक तालिका के 100 नाली को 2 सेकंड (ओह, इस सामग्री और इसके "शीर्ष" प्रदर्शन) से अधिक या कम नहीं लेता है।

इस मामले में खुद को प्रस्तुत करने में केवल (860 एमएस) लिया गया, हालांकि, पेज 2.2 सेकंड के लिए जम गया और उपयोगकर्ता परेशान था।

ठीक है, चलो 300 पंक्तियों के साथ एक तालिका प्रदान करने का प्रयास करें। और ड्रम रोल, हम थोड़ा इंतजार कर रहे हैं और हम देखते हैं कि कुल मिलाकर लगभग 10 सेकंड स्क्रिप्टिंग और रेंडरिंग पर खर्च किए गए थे। यही है, इस मामले में जब उपयोगकर्ता 300 पंक्तियों में ऐसी तालिका प्रदर्शित करना चाहता है, तो उसका पृष्ठ 10 सेकंड के लिए स्थिर हो जाएगा। यह बहुत डरावना और आश्चर्यजनक है (वास्तव में नहीं)।

वास्तव में, मैं अभी भी उस समय की माप करने की कोशिश कर रहा था जिसमें 1000 तत्वों को खींचने में समय लगेगा, लेकिन मेरा दयनीय i7 इसे खड़ा नहीं कर सकता था और पृष्ठ लगातार गिर रहा था।
हम पहले से लागू समाधान के साथ बाद में ऐसा करने की कोशिश करेंगे।

समस्या का समाधान

और इसलिए, हर कोई ब्राउज़र-आधारित उपयोगिताओं का उपयोग करके माप ले सकता है, लेकिन इस समस्या का कोई समाधान नहीं है।

समस्या के बहुत सार पर तर्क करके यह निर्णय मेरे द्वारा लिया गया था।

समस्या की एक सही समझ इसके समाधान का कम से कम आधा है।

मुझे लगता है कि हर कोई समझता है कि यह इसलिए हो रहा है क्योंकि तालिका डेटा को पहले स्क्रिप्ट द्वारा संसाधित किया जाता है और फिर एक टुकड़े में थूक दिया जाता है । बदले में, यह ठीक है कि हम एक विशेषता निलंबन क्यों देखते हैं।

समस्या पाई गई। अब यह पता लगाना बाकी है कि इसे कैसे हल किया जाए। दिमाग में आने वाला सबसे पहला उपाय सबसे सरल है। यदि समस्या एक ही बार में सभी डेटा को संसाधित कर रही है, तो आपको तालिका को भागों में डेटा को संसाधित करने की आवश्यकता है।

लेकिन वह कैसे करें?

चलिए सोचते हैं कि इसके लिए हमारे पास क्या है। पहली बात जो दिमाग में आती है वह है ट्रैक बाय फंक्शन। डेटा स्रोत बदलते समय, पूरी तालिका को फिर से प्रस्तुत नहीं किया जाएगा, लेकिन केवल इसके परिवर्तन।

आइए इस फ़ंक्शन को हमारी तालिका में जोड़ें:

<mat-table [trackBy]="trackByFn" [dataSource]="commonDataSource">

ठीक है, लेकिन हमारे पास ऐसी कोई स्थिति नहीं है कि तालिका डेटा किसी तरह बदल रहा है, और यह वह नहीं है जिसके बारे में अभी बातचीत हो रही है। लेकिन क्या होगा अगर हम पाइप लिखते हैं, जो, डेटा स्रोत को इनिशियलाइज़ करते समय, डेटा को तोड़ देगा और इसे बैचों में टेबल पर दे देगा। बदले में, TrackBy फ़ंक्शन एक पूर्ण रेंडरर से बचने में मदद करेगा।

@Pipe({
  name: 'splitSchedule'
})
export class SplitPipe implements PipeTransform {
  public transform(value: any, takeBy: number = 4, throttleTime: number = 40): Observable<Array<any>> {
    return Array.isArray(value)
      ? this.getSplittedThread(value, takeBy, throttleTime)
      : of(value);
  }

  private getSplittedThread(data: Array<any>, takeBy: number, throttleTime: number): Observable<Array<any>> {
    const repeatNumber = Math.ceil(data.length / takeBy);
    return timer(0, throttleTime).pipe(
      map((current) => data.slice(0, takeBy * ++current)),
      take(repeatNumber)
    );
  }
}

यहां कोड का एक छोटा सा टुकड़ा है जो आपके हार्डवेयर को इतनी बड़ी तालिकाओं को प्रस्तुत करने में मदद करेगा।

इस पाइप को हमारे डेटा स्रोत पर लागू करें।


<mat-table [trackBy]="trackByFn"
           [dataSource]="commonDataSource | splitSchedule | async">

अब आइए माप लेने की कोशिश करें। 100, 300 और 1000 तत्वों को प्रस्तुत करना।

और हम क्या देखते हैं? वास्तव में सफलता वह नहीं है जिसकी हमें उम्मीद थी:

300 तत्वों ने 1 सेकंड तेजी से प्रदान किया
1000 11 सेकंड में गाया और टैब मर नहीं गया
और 100 तत्वों को आम तौर पर 150 एमएस लंबे समय तक प्रदान किया गया

लेकिन निष्कर्ष निकालने में जल्दबाजी न करें, आइए पहले दोनों मामलों में पृष्ठ के व्यवहार को देखें।

जैसा कि आप देख सकते हैं, सामान्य स्थिति में, पेज कुछ सेकंड के लिए जमा हो जाता है और उपयोगकर्ता इस समय कुछ भी नहीं कर सकता है, जबकि ट्रैकबी के लिंक के साथ हमारे पाइप का उपयोग करने से उपयोगकर्ता को लगभग तात्कालिक तालिका आरंभीकरण मिलता है और एप्लिकेशन का उपयोग करते समय कोई असुविधा नहीं होती है।

आशा है कि यह लेख किसी की मदद करता है।

परीक्षण आवेदन के लिए स्रोत कोड स्टैक ब्लिट्ज पर है ।

कुछ चरणों में MatTable प्रतिपादन की गति

परीक्षण का मामला

समस्या का समाधान

More articles: