परफॉर्मेंस को अनलॉक करना: लिस्ट ऑप्टिमाइज़ेशन के लिए रिएक्ट रीकंसिलिएशन कीज़ का गहन विश्लेषण

आधुनिक वेब डेवलपमेंट की दुनिया में, डायनामिक यूजर इंटरफेस बनाना जो डेटा परिवर्तनों पर तेजी से प्रतिक्रिया करते हैं, सर्वोपरि है। रिएक्ट, अपने कंपोनेंट-आधारित आर्किटेक्चर और डिक्लेरेटिव प्रकृति के साथ, इन इंटरफेस के निर्माण के लिए एक वैश्विक मानक बन गया है। रिएक्ट की दक्षता के केंद्र में रीकंसिलिएशन नामक एक प्रक्रिया है, जिसमें वर्चुअल DOM शामिल है। हालांकि, सबसे शक्तिशाली उपकरणों का भी अक्षम रूप से उपयोग किया जा सकता है, और एक सामान्य क्षेत्र जहां नए और अनुभवी दोनों डेवलपर्स गलती करते हैं, वह है लिस्ट्स का रेंडरिंग।

आपने शायद data.map(item => <div>{item.name}</div>) जैसा कोड अनगिनत बार लिखा होगा। यह सरल, लगभग तुच्छ लगता है। फिर भी, इस सादगी के नीचे एक महत्वपूर्ण परफॉर्मेंस विचार छिपा है, जिसे अगर नजरअंदाज किया गया, तो यह सुस्त एप्लिकेशन और हैरान करने वाले बग्स का कारण बन सकता है। समाधान? एक छोटा लेकिन शक्तिशाली प्रॉप: key।

यह व्यापक गाइड आपको रिएक्ट की रीकंसिलिएशन प्रक्रिया और लिस्ट रेंडरिंग में कीज़ (keys) की अनिवार्य भूमिका पर एक गहन यात्रा पर ले जाएगा। हम न केवल 'क्या' बल्कि 'क्यों' का भी पता लगाएंगे - कीज़ क्यों आवश्यक हैं, उन्हें सही तरीके से कैसे चुनें, और उन्हें गलत चुनने के महत्वपूर्ण परिणाम क्या होते हैं। अंत तक, आपके पास अधिक परफॉर्मेंस वाले, स्थिर और पेशेवर रिएक्ट एप्लिकेशन लिखने का ज्ञान होगा।

अध्याय 1: रिएक्ट के रीकंसिलिएशन और वर्चुअल DOM को समझना

इससे पहले कि हम कीज़ (keys) के महत्व को समझें, हमें पहले उस मूलभूत तंत्र को समझना होगा जो रिएक्ट को तेज बनाता है: रीकंसिलिएशन, जो वर्चुअल DOM (VDOM) द्वारा संचालित होता है।

वर्चुअल DOM क्या है?

ब्राउज़र के डॉक्यूमेंट ऑब्जेक्ट मॉडल (DOM) के साथ सीधे इंटरैक्ट करना कम्प्यूटेशनल रूप से महंगा है। हर बार जब आप DOM में कुछ बदलते हैं - जैसे एक नोड जोड़ना, टेक्स्ट अपडेट करना, या स्टाइल बदलना - ब्राउज़र को बहुत सारा काम करना पड़ता है। इसे पूरे पेज के लिए स्टाइल और लेआउट की फिर से गणना करने की आवश्यकता हो सकती है, इस प्रक्रिया को रिफ्लो और रिपेंट के रूप में जाना जाता है। एक जटिल, डेटा-संचालित एप्लिकेशन में, बार-बार सीधे DOM मैनिपुलेशन से परफॉर्मेंस जल्दी ही धीमी हो सकती है।

रिएक्ट इस समस्या को हल करने के लिए एक एब्स्ट्रैक्शन लेयर पेश करता है: वर्चुअल DOM। VDOM वास्तविक DOM का एक हल्का, इन-मेमोरी प्रतिनिधित्व है। इसे अपने UI के ब्लूप्रिंट के रूप में सोचें। जब आप रिएक्ट को UI अपडेट करने के लिए कहते हैं (उदाहरण के लिए, किसी कंपोनेंट की स्टेट बदलकर), तो रिएक्ट तुरंत वास्तविक DOM को नहीं छूता है। इसके बजाय, यह निम्नलिखित कदम उठाता है:

1. एक नया VDOM ट्री बनाया जाता है जो अपडेटेड स्टेट का प्रतिनिधित्व करता है।
2. इस नए VDOM ट्री की तुलना पिछले VDOM ट्री से की जाती है। इस तुलना प्रक्रिया को "डिफिंग" (diffing) कहा जाता है।
3. रिएक्ट उन न्यूनतम परिवर्तनों का पता लगाता है जो पुराने VDOM को नए में बदलने के लिए आवश्यक हैं।
4. इन न्यूनतम परिवर्तनों को फिर एक साथ बैच किया जाता है और एक ही, कुशल ऑपरेशन में वास्तविक DOM पर लागू किया जाता है।

यह प्रक्रिया, जिसे रीकंसिलिएशन के रूप में जाना जाता है, वही है जो रिएक्ट को इतना परफॉर्मेंट बनाती है। पूरे घर को फिर से बनाने के बजाय, रिएक्ट एक विशेषज्ञ ठेकेदार की तरह काम करता है जो ठीक से पहचानता है कि कौन सी विशिष्ट ईंटों को बदलने की आवश्यकता है, जिससे काम और व्यवधान कम से कम हो।

अध्याय 2: बिना कीज़ (Keys) के लिस्ट रेंडर करने में समस्या

अब, देखते हैं कि यह सुरुचिपूर्ण प्रणाली कहाँ मुश्किल में पड़ सकती है। एक साधारण कंपोनेंट पर विचार करें जो उपयोगकर्ताओं की एक सूची प्रस्तुत करता है:

function UserList({ users }) {
  return (
    <ul>
      {users.map(user => (
        <li>{user.name}</li>
      ))}
    </ul>
  );
}

जब यह कंपोनेंट पहली बार रेंडर होता है, तो रिएक्ट एक VDOM ट्री बनाता है। यदि हम users ऐरे के *अंत* में एक नया उपयोगकर्ता जोड़ते हैं, तो रिएक्ट का डिफिंग एल्गोरिथ्म इसे आसानी से संभालता है। यह पुरानी और नई सूचियों की तुलना करता है, अंत में एक नया आइटम देखता है, और बस वास्तविक DOM में एक नया <li> जोड़ देता है। कुशल और सरल।

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

मान लें कि हमारी प्रारंभिक सूची है:

• Alice
• Bob

और एक अपडेट के बाद, यह बन जाती है:

• Charlie
• Alice
• Bob

बिना किसी यूनिक आइडेंटिफायर के, रिएक्ट दोनों सूचियों की तुलना उनके क्रम (इंडेक्स) के आधार पर करता है। यहाँ वह क्या देखता है:

• पोजीशन 0: पुराना आइटम "Alice" था। नया आइटम "Charlie" है। रिएक्ट यह निष्कर्ष निकालता है कि इस पोजीशन पर कंपोनेंट को अपडेट करने की आवश्यकता है। यह मौजूदा DOM नोड को "Alice" से "Charlie" में बदलने के लिए म्यूटेट करता है।
• पोजीशन 1: पुराना आइटम "Bob" था। नया आइटम "Alice" है। रिएक्ट दूसरे DOM नोड को "Bob" से "Alice" में बदलने के लिए म्यूटेट करता है।
• पोजीशन 2: यहां पहले कोई आइटम नहीं था। नया आइटम "Bob" है। रिएक्ट "Bob" के लिए एक नया DOM नोड बनाता है और डालता है।

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

यही कारण है कि, यदि आप उपरोक्त कोड चलाते हैं, तो आपके ब्राउज़र का डेवलपर कंसोल एक चेतावनी दिखाएगा: "Warning: Each child in a list should have a unique 'key' prop." रिएक्ट आपको स्पष्ट रूप से बता रहा है कि उसे अपना काम कुशलता से करने के लिए मदद की ज़रूरत है।

अध्याय 3: key प्रॉप बचाव के लिए

key प्रॉप वह संकेत है जिसकी रिएक्ट को आवश्यकता है। यह एक विशेष स्ट्रिंग एट्रिब्यूट है जो आप एलिमेंट्स की सूची बनाते समय प्रदान करते हैं। कीज़ (Keys) प्रत्येक एलिमेंट को री-रेंडर के दौरान एक स्थिर और यूनिक पहचान देती हैं।

आइए अपने UserList कंपोनेंट को कीज़ के साथ फिर से लिखें:

function UserList({ users }) {
  return (
    <ul>
      {users.map(user => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

यहां, हम मानते हैं कि प्रत्येक user ऑब्जेक्ट में एक यूनिक id प्रॉपर्टी है (उदाहरण के लिए, डेटाबेस से)। अब, आइए अपने परिदृश्य पर फिर से विचार करें।

प्रारंभिक डेटा:

[{ id: 'u1', name: 'Alice' }, { id: 'u2', name: 'Bob' }]

अपडेटेड डेटा:

[{ id: 'u3', name: 'Charlie' }, { id: 'u1', name: 'Alice' }, { id: 'u2', name: 'Bob' }]

कीज़ के साथ, रिएक्ट की डिफिंग प्रक्रिया बहुत स्मार्ट हो जाती है:

1. रिएक्ट नए VDOM में <ul> के चिल्ड्रेन को देखता है और उनकी कीज़ की जाँच करता है। उसे u3, u1, और u2 दिखाई देते हैं।
2. फिर यह पिछले VDOM के चिल्ड्रेन और उनकी कीज़ की जाँच करता है। उसे u1 और u2 दिखाई देते हैं।
3. रिएक्ट जानता है कि u1 और u2 कीज़ वाले कंपोनेंट पहले से मौजूद हैं। इसे उन्हें म्यूटेट करने की आवश्यकता नहीं है; इसे बस उनके संबंधित DOM नोड्स को उनकी नई पोजीशन पर ले जाने की आवश्यकता है।
4. रिएक्ट देखता है कि u3 की (key) नई है। यह "Charlie" के लिए एक नया कंपोनेंट और DOM नोड बनाता है और इसे शुरुआत में डालता है।

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

अध्याय 4: सही Key चुनना - स्वर्णिम नियम

key प्रॉप की प्रभावशीलता पूरी तरह से सही मान चुनने पर निर्भर करती है। इसके लिए स्पष्ट सर्वोत्तम प्रथाएं और खतरनाक एंटी-पैटर्न हैं जिनसे अवगत होना चाहिए।

सबसे अच्छी Key: यूनिक और स्थिर आईडी

आदर्श की (key) एक ऐसा मान है जो सूची के भीतर किसी आइटम को विशिष्ट और स्थायी रूप से पहचानता है। यह लगभग हमेशा आपके डेटा स्रोत से एक यूनिक आईडी होती है।

• इसे अपने सिबलिंग्स (siblings) के बीच यूनिक होना चाहिए। कीज़ को विश्व स्तर पर यूनिक होने की आवश्यकता नहीं है, केवल उस स्तर पर प्रस्तुत किए जा रहे एलिमेंट्स की सूची के भीतर यूनिक होना चाहिए। एक ही पेज पर दो अलग-अलग सूचियों में समान की वाले आइटम हो सकते हैं।
• यह स्थिर होनी चाहिए। किसी विशिष्ट डेटा आइटम के लिए की (key) रेंडर के बीच नहीं बदलनी चाहिए। यदि आप ऐलिस के लिए डेटा फिर से प्राप्त करते हैं, तो उसकी id वही रहनी चाहिए।

कीज़ के लिए उत्कृष्ट स्रोत शामिल हैं:

• डेटाबेस प्राइमरी कीज़ (जैसे, user.id, product.sku)
• यूनिवर्सली यूनिक आइडेंटिफायर्स (UUIDs)
• आपके डेटा से एक यूनिक, अपरिवर्तनीय स्ट्रिंग (जैसे, किसी पुस्तक का ISBN)

// अच्छा: डेटा से एक स्थिर, यूनिक आईडी का उपयोग करना।
<div>
  {products.map(product => (
    <ProductItem key={product.sku} product={product} />
  ))}
</div>

एंटी-पैटर्न: ऐरे इंडेक्स को Key के रूप में उपयोग करना

एक आम गलती है ऐरे इंडेक्स को की (key) के रूप में उपयोग करना:

// बुरा: ऐरे इंडेक्स को की के रूप में उपयोग करना।
<div>
  {items.map((item, index) => (
    <ListItem key={index} item={item} />
  ))}
</div>

हालांकि यह रिएक्ट चेतावनी को शांत कर देगा, यह गंभीर समस्याओं को जन्म दे सकता है और आमतौर पर इसे एक एंटी-पैटर्न माना जाता है। इंडेक्स को की के रूप में उपयोग करना रिएक्ट को बताता है कि किसी आइटम की पहचान सूची में उसकी स्थिति से जुड़ी हुई है। यह मूल रूप से बिना की के होने जैसी ही समस्या है जब सूची को फिर से व्यवस्थित किया जा सकता है, फ़िल्टर किया जा सकता है, या शुरुआत या बीच से आइटम जोड़े/हटाए जा सकते हैं।

स्टेट मैनेजमेंट बग:

इंडेक्स कीज़ का उपयोग करने का सबसे खतरनाक दुष्प्रभाव तब दिखाई देता है जब आपके लिस्ट आइटम अपनी खुद की स्टेट को मैनेज करते हैं। इनपुट फ़ील्ड्स की एक सूची की कल्पना करें:

function UnstableList() {
  const [items, setItems] = React.useState([{ id: 1, text: 'First' }, { id: 2, text: 'Second' }]);

  const handleAddItemToTop = () => {
    setItems([{ id: 3, text: 'New Top' }, ...items]);
  };

  return (
    <div>
      <button onClick={handleAddItemToTop}>Add to Top</button>
      {items.map((item, index) => (
        <div key={index}>
          <label>{item.text}: </label>
          <input type="text" />
        </div>
      ))}
    </div>
  );
}

इस मानसिक अभ्यास का प्रयास करें:

1. सूची "First" और "Second" के साथ रेंडर होती है।
2. आप पहले इनपुट फ़ील्ड में ("First" वाले में) "Hello" टाइप करते हैं।
3. आप "Add to Top" बटन पर क्लिक करते हैं।

आप क्या होने की उम्मीद करते हैं? आप उम्मीद करेंगे कि "New Top" के लिए एक नया, खाली इनपुट दिखाई देगा, और "First" के लिए इनपुट (जिसमें अभी भी "Hello" है) नीचे चला जाएगा। वास्तव में क्या होता है? पहली पोजीशन (इंडेक्स 0) पर इनपुट फ़ील्ड, जिसमें अभी भी "Hello" है, बना रहता है। लेकिन अब यह नए डेटा आइटम, "New Top" से जुड़ा हुआ है। इनपुट कंपोनेंट की स्टेट (इसका आंतरिक मान) इसकी पोजीशन (key=0) से जुड़ी है, न कि उस डेटा से जिसका उसे प्रतिनिधित्व करना चाहिए। यह इंडेक्स कीज़ के कारण होने वाला एक क्लासिक और भ्रमित करने वाला बग है।

यदि आप बस key={index} को key={item.id} में बदलते हैं, तो समस्या हल हो जाती है। रिएक्ट अब कंपोनेंट की स्टेट को डेटा की स्थिर आईडी के साथ सही ढंग से संबद्ध करेगा।

इंडेक्स Key का उपयोग करना कब स्वीकार्य है?

ऐसी दुर्लभ स्थितियाँ हैं जहाँ इंडेक्स का उपयोग करना सुरक्षित है, लेकिन आपको इन सभी शर्तों को पूरा करना होगा:

1. सूची स्थिर है: इसे कभी भी फिर से व्यवस्थित, फ़िल्टर या अंत के अलावा कहीं से भी आइटम जोड़े/हटाए नहीं जाएंगे।
2. सूची में आइटम की कोई स्थिर आईडी नहीं है।
3. प्रत्येक आइटम के लिए रेंडर किए गए कंपोनेंट सरल हैं और उनकी कोई आंतरिक स्टेट नहीं है।

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

सबसे बुरा तरीका: `Math.random()`

कभी भी Math.random() या किसी अन्य गैर-नियतात्मक मान का उपयोग की (key) के लिए न करें:

// बहुत बुरा: ऐसा न करें!
<div>
  {items.map(item => (
    <ListItem key={Math.random()} item={item} />
  ))}
</div>

Math.random() द्वारा उत्पन्न की (key) हर एक रेंडर पर अलग होने की गारंटी है। यह रिएक्ट को बताता है कि पिछले रेंडर से कंपोनेंट्स की पूरी सूची नष्ट हो गई है और पूरी तरह से अलग कंपोनेंट्स की एक नई सूची बनाई गई है। यह रिएक्ट को सभी पुराने कंपोनेंट्स को अनमाउंट करने (उनकी स्टेट को नष्ट करने) और सभी नए कंपोनेंट्स को माउंट करने के लिए मजबूर करता है। यह रीकंसिलिएशन के उद्देश्य को पूरी तरह से विफल कर देता है और परफॉर्मेंस के लिए सबसे खराब संभव विकल्प है।

अध्याय 5: उन्नत अवधारणाएँ और सामान्य प्रश्न

Keys और `React.Fragment`

कभी-कभी आपको map कॉलबैक से कई एलिमेंट्स लौटाने की आवश्यकता होती है। ऐसा करने का मानक तरीका React.Fragment है। जब आप ऐसा करते हैं, तो key को Fragment कंपोनेंट पर ही रखा जाना चाहिए।

function Glossary({ terms }) {
  return (
    <dl>
      {terms.map(term => (
        // की (key) Fragment पर जाती है, चिल्ड्रेन पर नहीं।
        <React.Fragment key={term.id}>
          <dt>{term.name}</dt>
          <dd>{term.definition}</dd>
        </React.Fragment>
      ))}
    </dl>
  );
}

महत्वपूर्ण: शॉर्टहैंड सिंटैक्स <>...</> कीज़ (keys) का समर्थन नहीं करता है। यदि आपकी सूची को फ्रैगमेंट्स की आवश्यकता है, तो आपको स्पष्ट <React.Fragment> सिंटैक्स का उपयोग करना होगा।

Keys को केवल सिबलिंग्स (Siblings) के बीच यूनिक होना चाहिए

एक आम गलतफहमी यह है कि कीज़ को आपके पूरे एप्लिकेशन में विश्व स्तर पर यूनिक होना चाहिए। यह सच नहीं है। एक की (key) को केवल अपने तत्काल सिबलिंग्स की सूची के भीतर यूनिक होना चाहिए।

function CourseRoster({ courses }) {
  return (
    <div>
      {courses.map(course => (
        <div key={course.id}>  {/* कोर्स के लिए की */} 
          <h3>{course.title}</h3>
          <ul>
            {course.students.map(student => (
              // इस स्टूडेंट की (key) को केवल इस विशिष्ट कोर्स की स्टूडेंट सूची के भीतर यूनिक होना चाहिए।
              <li key={student.id}>{student.name}</li>
            ))}
          </ul>
        </div>
      ))}
    </div>
  );
}

उपरोक्त उदाहरण में, दो अलग-अलग कोर्स में id: 's1' वाला एक स्टूडेंट हो सकता है। यह बिल्कुल ठीक है क्योंकि कीज़ का मूल्यांकन अलग-अलग पैरेंट <ul> एलिमेंट्स के भीतर किया जा रहा है।

कंपोनेंट स्टेट को जानबूझकर रीसेट करने के लिए Keys का उपयोग करना

जबकि कीज़ मुख्य रूप से लिस्ट ऑप्टिमाइज़ेशन के लिए हैं, वे एक गहरे उद्देश्य की पूर्ति करती हैं: वे एक कंपोनेंट की पहचान को परिभाषित करती हैं। यदि किसी कंपोनेंट की की (key) बदलती है, तो रिएक्ट मौजूदा कंपोनेंट को अपडेट करने का प्रयास नहीं करेगा। इसके बजाय, यह पुराने कंपोनेंट (और उसके सभी चिल्ड्रेन) को नष्ट कर देगा और स्क्रैच से एक नया बनाएगा। यह पुराने इंस्टेंस को अनमाउंट करता है और एक नया माउंट करता है, जिससे इसकी स्टेट प्रभावी रूप से रीसेट हो जाती है।

यह एक कंपोनेंट को रीसेट करने का एक शक्तिशाली और डिक्लेरेटिव तरीका हो सकता है। उदाहरण के लिए, एक UserProfile कंपोनेंट की कल्पना करें जो userId के आधार पर डेटा प्राप्त करता है।

function App() {
  const [userId, setUserId] = React.useState('user-1');

  return (
    <div>
      <button onClick={() => setUserId('user-1')}>View User 1</button>
      <button onClick={() => setUserId('user-2')}>View User 2</button>
      
      <UserProfile key={userId} id={userId} />
    </div>
  );
}

UserProfile कंपोनेंट पर key={userId} रखकर, हम गारंटी देते हैं कि जब भी userId बदलेगा, तो पूरा UserProfile कंपोनेंट फेंक दिया जाएगा और एक नया बनाया जाएगा। यह उन संभावित बग्स को रोकता है जहां पिछले उपयोगकर्ता की प्रोफ़ाइल से स्टेट (जैसे फॉर्म डेटा या प्राप्त सामग्री) बनी रह सकती है। यह कंपोनेंट की पहचान और जीवनचक्र को प्रबंधित करने का एक स्वच्छ और स्पष्ट तरीका है।

निष्कर्ष: बेहतर रिएक्ट कोड लिखना

key प्रॉप कंसोल चेतावनी को शांत करने के एक तरीके से कहीं बढ़कर है। यह रिएक्ट के लिए एक मौलिक निर्देश है, जो उसके रीकंसिलिएशन एल्गोरिथ्म को कुशलतापूर्वक और सही ढंग से काम करने के लिए आवश्यक महत्वपूर्ण जानकारी प्रदान करता है। कीज़ के उपयोग में महारत हासिल करना एक पेशेवर रिएक्ट डेवलपर की पहचान है।

आइए मुख्य बातों को सारांशित करें:

• कीज़ परफॉर्मेंस के लिए आवश्यक हैं: वे रिएक्ट के डिफिंग एल्गोरिथ्म को बिना किसी अनावश्यक DOM म्यूटेशन के सूची में एलिमेंट्स को कुशलतापूर्वक जोड़ने, हटाने और फिर से व्यवस्थित करने में सक्षम बनाती हैं।
• हमेशा स्थिर और यूनिक आईडी का उपयोग करें: सबसे अच्छी की (key) आपके डेटा से एक यूनिक आइडेंटिफायर है जो रेंडर के दौरान नहीं बदलता है।
• ऐरे इंडेक्स को कीज़ के रूप में उपयोग करने से बचें: किसी आइटम के इंडेक्स को उसकी की (key) के रूप में उपयोग करने से खराब परफॉर्मेंस और सूक्ष्म, निराशाजनक स्टेट मैनेजमेंट बग्स हो सकते हैं, खासकर डायनामिक सूचियों में।
• कभी भी रैंडम या अस्थिर कीज़ का उपयोग न करें: यह सबसे खराब स्थिति है, क्योंकि यह रिएक्ट को हर रेंडर पर कंपोनेंट्स की पूरी सूची को फिर से बनाने के लिए मजबूर करता है, जिससे परफॉर्मेंस और स्टेट नष्ट हो जाती है।
• कीज़ कंपोनेंट की पहचान को परिभाषित करती हैं: आप इस व्यवहार का लाभ उठाकर किसी कंपोनेंट की की (key) को बदलकर उसकी स्टेट को जानबूझकर रीसेट कर सकते हैं।

इन सिद्धांतों को आत्मसात करके, आप न केवल तेज, अधिक विश्वसनीय रिएक्ट एप्लिकेशन लिखेंगे, बल्कि लाइब्रेरी के मूल मैकेनिक्स की गहरी समझ भी प्राप्त करेंगे। अगली बार जब आप किसी सूची को रेंडर करने के लिए किसी ऐरे पर मैप करें, तो key प्रॉप पर वह ध्यान दें जिसका वह हकदार है। आपके एप्लिकेशन की परफॉर्मेंस - और आपका भविष्य का स्व - इसके लिए आपको धन्यवाद देगा।