रीऐक्ट रेफ़ कॉलबैक में महारत हासिल करना: परफ़ॉर्मेंस ऑप्टिमाइज़ेशन के लिए बेहतरीन गाइड

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

रेफ़्स, रेंडर मेथड में बनाए गए DOM नोड्स या रीऐक्ट एलिमेंट्स तक पहुँचने का एक तरीका प्रदान करते हैं—फ़ोकस प्रबंधित करने, एनिमेशन ट्रिगर करने या थर्ड-पार्टी DOM लाइब्रेरी के साथ इंटीग्रेट करने जैसे कार्यों के लिए एक ज़रूरी एस्केप हैच। जबकि useRef फंक्शनल कॉम्पोनेंट में सरल मामलों के लिए स्टैंडर्ड बन गया है, कॉलबैक रेफ़्स ज़्यादा शक्तिशाली, बारीक कंट्रोल प्रदान करते हैं कि कब एक रेफ़रेंस सेट और अनसेट किया जाता है। हालाँकि, यह शक्ति एक बारीकी के साथ आती है: एक कॉलबैक रेफ़ एक कॉम्पोनेंट के लाइफ़सायकल के दौरान कई बार फ़ायर हो सकता है, जिससे अगर सही तरीके से नहीं संभाला गया तो परफ़ॉर्मेंस बॉटलनेक और बग हो सकते हैं।

यह व्यापक गाइड रीऐक्ट रेफ़ कॉलबैक को रहस्यमय बना देगा। हम एक्सप्लोर करेंगे:

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

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

एक क्विक रिफ़्रेशर: कॉलबैक रेफ़्स क्या हैं?

ऑप्टिमाइज़ेशन में गोता लगाने से पहले, आइए संक्षेप में फिर से देखते हैं कि कॉलबैक रेफ़ क्या है। useRef() या React.createRef() द्वारा बनाए गए रेफ़ ऑब्जेक्ट को पास करने के बजाय, आप ref एट्रिब्यूट को एक फ़ंक्शन पास करते हैं। जब कॉम्पोनेंट माउंट और अनमाउंट होता है, तो यह फ़ंक्शन रीऐक्ट द्वारा एक्सिक्यूट किया जाता है।

जब कॉम्पोनेंट माउंट होता है, तो रीऐक्ट रेफ़ कॉलबैक को DOM एलिमेंट के साथ एक आर्ग्यूमेंट के रूप में कॉल करेगा, और जब कॉम्पोनेंट अनमाउंट होता है, तो यह null के साथ एक आर्ग्यूमेंट के रूप में कॉल करेगा। यह आपको ठीक उस समय सटीक कंट्रोल देता है जब रेफ़रेंस उपलब्ध होता है या नष्ट होने वाला होता है।

यहाँ एक फंक्शनल कॉम्पोनेंट में एक सरल उदाहरण है:

            import React, { useState } from 'react';

function TextInputWithFocusButton() {
  let textInput = null;

  const setTextInputRef = element => {
    console.log('Ref callback fired with:', element);
    textInput = element;
  };

  const focusTextInput = () => {
    // Focus the text input using the raw DOM API
    if (textInput) textInput.focus();
  };

  return (
    <div>
      <input type="text" ref={setTextInputRef} />
      <button onClick={focusTextInput}>
        Focus the text input
      </button>
    </div>
  );
}
            

              
                Copy
              
            
          

इस उदाहरण में, setTextInputRef हमारा कॉलबैक रेफ़ है। इसे <input> एलिमेंट के साथ कॉल किया जाएगा जब इसे रेंडर किया जाएगा, जिससे हम इसे स्टोर कर सकते हैं और बाद में focus() को कॉल करने के लिए उपयोग कर सकते हैं।

मूल समस्या: रेफ़ कॉलबैक दो बार क्यों फ़ायर होते हैं?

केंद्रीय व्यवहार जो अक्सर डेवलपर्स को भ्रमित करता है, वह है कॉलबैक का दो बार आह्वान। जब एक कॉलबैक रेफ़ वाला कॉम्पोनेंट रेंडर होता है, तो कॉलबैक फ़ंक्शन आमतौर पर लगातार दो बार कॉल किया जाता है:

1. पहला कॉल: null के साथ आर्ग्यूमेंट के रूप में।
2. दूसरा कॉल: DOM एलिमेंट इंस्टेंस के साथ आर्ग्यूमेंट के रूप में।

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

समस्या, हालाँकि, यह माउंट/अनमाउंट चक्र नहीं है। वास्तविक परफ़ॉर्मेंस समस्या तब उत्पन्न होती है जब यह डबल-फ़ायरिंग हर री-रेंडर पर होती है, यहाँ तक कि तब भी जब कॉम्पोनेंट की स्थिति रेफ़ से पूरी तरह से असंबंधित तरीके से अपडेट होती है।

इनलाइन फ़ंक्शन की कमज़ोरी

एक फंक्शनल कॉम्पोनेंट के अंदर इस दिखने में निर्दोष इम्प्लीमेंटेशन पर विचार करें जो री-रेंडर होता है:

            import React, { useState } from 'react';

function FrequentUpdatesComponent() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <h3>Counter: {count}</h3>
      <button onClick={() => setCount(c => c + 1)}>Increment</button>
      <div
        ref={(node) => {
          // This is an inline function!
          console.log('Ref callback fired with:', node);
        }}
      >
        I am the referenced element.
      </div>
    </div>
  );
}
            

              
                Copy
              
            
          

यदि आप इस कोड को चलाते हैं और "इंक्रीमेंट" बटन पर क्लिक करते हैं, तो आपको हर क्लिक पर अपने कंसोल में निम्नलिखित दिखाई देगा:

            Ref callback fired with: null
Ref callback fired with: <div>...</div>
            

              
                Copy
              
            
          

यह क्यों होता है? क्योंकि प्रत्येक रेंडर पर, आप ref प्रोप के लिए एक ब्रांड न्यू फ़ंक्शन इंस्टेंस बना रहे हैं: (node) => { ... }। अपने रिकॉन्सिलिएशन प्रोसेस के दौरान, रीऐक्ट पिछले रेंडर से प्रोप्स की तुलना वर्तमान से करता है। यह देखता है कि ref प्रोप बदल गया है (पुराने फ़ंक्शन इंस्टेंस से नए में)। रीऐक्ट का कॉन्ट्रैक्ट स्पष्ट है: यदि रेफ़ कॉलबैक बदलता है, तो उसे पहले null के साथ कॉल करके पुराने रेफ़ को साफ़ करना होगा, और फिर DOM नोड के साथ कॉल करके नया सेट करना होगा। यह हर रेंडर पर अनावश्यक रूप से क्लीनअप/सेटअप चक्र को ट्रिगर करता है।

एक साधारण console.log के लिए, यह एक मामूली परफ़ॉर्मेंस हिट है। लेकिन कल्पना कीजिए कि आपका कॉलबैक कुछ महंगा करता है:

• जटिल इवेंट लिस्नर को अटैच और डिटेच करना (जैसे, `scroll`, `resize`)।
• एक भारी थर्ड-पार्टी लाइब्रेरी को इनिशियलाइज़ करना (जैसे D3.js चार्ट या एक मैपिंग लाइब्रेरी)।
• DOM माप लेना जिससे लेआउट रिफ्लो हो।

प्रत्येक स्थिति अपडेट पर इस तर्क को एक्सिक्यूट करने से आपके एप्लिकेशन की परफ़ॉर्मेंस गंभीर रूप से कम हो सकती है और सूक्ष्म, हार्ड-टू-ट्रेस बग आ सकते हैं।

समाधान: `useCallback` के साथ मेमोइज़ करना

इस समस्या का समाधान यह सुनिश्चित करना है कि रीऐक्ट री-रेंडर के दौरान रेफ़ कॉलबैक के लिए ठीक उसी फ़ंक्शन इंस्टेंस को प्राप्त करे, जब तक कि हम इसे स्पष्ट रूप से बदलना नहीं चाहते। यह useCallback हुक के लिए एकदम सही उपयोग का मामला है।

useCallback एक कॉलबैक फ़ंक्शन का मेमोराइज़्ड वर्ज़न लौटाता है। यह मेमोराइज़्ड वर्ज़न तभी बदलता है जब उसकी डिपेंडेंसी एरे में से कोई एक डिपेंडेंसी बदल जाती है। एक खाली डिपेंडेंसी एरे ([]) प्रदान करके, हम एक स्टेबल फ़ंक्शन बना सकते हैं जो कॉम्पोनेंट के पूरे लाइफ़टाइम तक बना रहता है।

आइए useCallback का उपयोग करके हमारे पिछले उदाहरण को रिफ़ैक्टर करें:

            import React, { useState, useCallback } from 'react';

function OptimizedComponent() {
  const [count, setCount] = useState(0);

  // Create a stable callback function with useCallback
  const myRefCallback = useCallback(node => {
    // This logic now runs only when the component mounts and unmounts
    console.log('Ref callback fired with:', node);
    if (node !== null) {
      // You can perform setup logic here
      console.log('Element is mounted!');
    }
  }, []); // <-- Empty dependency array means the function is created only once

  return (
    <div>
      <h3>Counter: {count}</h3>
      <button onClick={() => setCount(c => c + 1)}>Increment</button>
      <div ref={myRefCallback}>
        I am the referenced element.
      </div>
    </div>
  );
}
            

              
                Copy
              
            
          

अब, जब आप इस ऑप्टिमाइज़्ड वर्ज़न को चलाते हैं, तो आपको कंसोल लॉग कुल मिलाकर सिर्फ़ दो बार दिखाई देगा:

1. एक बार जब कॉम्पोनेंट शुरू में माउंट होता है (Ref callback fired with: <div>...</div>)।
2. एक बार जब कॉम्पोनेंट अनमाउंट होता है (Ref callback fired with: null)।

"इंक्रीमेंट" बटन पर क्लिक करने से अब रेफ़ कॉलबैक ट्रिगर नहीं होगा। हमने हर री-रेंडर पर अनावश्यक क्लीनअप/सेटअप चक्र को सफलतापूर्वक रोक दिया है। रीऐक्ट बाद के रेंडर पर ref प्रोप के लिए उसी फ़ंक्शन इंस्टेंस को देखता है और सही ढंग से निर्धारित करता है कि किसी बदलाव की ज़रूरत नहीं है।

एडवांस परिदृश्य और बेहतरीन तरीके

जबकि एक खाली डिपेंडेंसी एरे आम है, ऐसे परिदृश्य हैं जहाँ आपके रेफ़ कॉलबैक को प्रोप्स या स्थिति में बदलावों पर प्रतिक्रिया करने की ज़रूरत होती है। यह वह जगह है जहाँ useCallback की डिपेंडेंसी एरे की शक्ति वास्तव में चमकती है।

अपने कॉलबैक में डिपेंडेंसी को संभालना

कल्पना कीजिए कि आपको अपने रेफ़ कॉलबैक के भीतर कुछ तर्क चलाने की ज़रूरत है जो स्थिति या एक प्रोप के एक हिस्से पर निर्भर करता है। उदाहरण के लिए, वर्तमान थीम के आधार पर एक `data-` एट्रिब्यूट सेट करना।

            function ThemedComponent({ theme }) {
  const [internalState, setInternalState] = useState(0);

  const themedRefCallback = useCallback(node => {
    if (node !== null) {
      // This callback now depends on the 'theme' prop
      console.log(`Setting theme attribute to: ${theme}`);
      node.setAttribute('data-theme', theme);
    }
  }, [theme]); // <-- Add 'theme' to the dependency array

  return (
    <div>
      <p>Current Theme: {theme}</p>
      <div ref={themedRefCallback}>This element's theme will update.</div>
      {/* ... imagine a button here to change the parent's theme ... */}
    </div>
  );
}
            

              
                Copy
              
            
          

इस उदाहरण में, हमने useCallback की डिपेंडेंसी एरे में theme जोड़ा है। इसका मतलब है:

• एक नया themedRefCallback फ़ंक्शन बनाया जाएगा सिर्फ़ जब theme प्रोप बदलता है।
• जब theme प्रोप बदलता है, तो रीऐक्ट नए फ़ंक्शन इंस्टेंस का पता लगाता है और रेफ़ कॉलबैक को फिर से चलाता है (पहले null के साथ, फिर एलिमेंट के साथ)।
• यह हमारे प्रभाव—`data-theme` एट्रिब्यूट सेट करना—को अपडेटेड theme वैल्यू के साथ फिर से चलाने की अनुमति देता है।

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

थर्ड-पार्टी लाइब्रेरी के साथ इंटीग्रेट करना

कॉलबैक रेफ़ के सबसे शक्तिशाली उपयोग मामलों में से एक थर्ड-पार्टी लाइब्रेरी के इंस्टेंस को इनिशियलाइज़ और नष्ट करना है जिन्हें DOM नोड से अटैच करने की ज़रूरत है। यह पैटर्न कॉलबैक के माउंट/अनमाउंट नेचर का पूरी तरह से लाभ उठाता है।

यहाँ एक चार्टिंग या मैप लाइब्रेरी जैसी लाइब्रेरी के प्रबंधन के लिए एक मज़बूत पैटर्न है:

            import React, { useRef, useCallback, useEffect } from 'react';
import SomeChartingLibrary from 'some-charting-library';

function ChartComponent({ data }) {
  // Use a ref to hold the library instance, not the DOM node
  const chartInstance = useRef(null);

  const chartContainerRef = useCallback(node => {
    // The node is null when the component unmounts
    if (node === null) {
      if (chartInstance.current) {
        console.log('Cleaning up chart instance...');
        chartInstance.current.destroy(); // Cleanup method from the library
        chartInstance.current = null;
      }
      return;
    }

    // The node exists, so we can initialize our chart
    console.log('Initializing chart instance...');
    const chart = new SomeChartingLibrary(node, {
      // Configuration options
      data: data,
    });
    chartInstance.current = chart;

  }, [data]); // Re-create the chart if the data prop changes

  return <div className="chart-container" ref={chartContainerRef} style={{ height: '400px' }} />;
}
            

              
                Copy
              
            
          

यह पैटर्न असाधारण रूप से साफ़ और लचीला है:

1. इनिशियलाइज़ेशन: जब `div` माउंट होता है, तो कॉलबैक को `node` प्राप्त होता है। यह चार्टिंग लाइब्रेरी का एक नया इंस्टेंस बनाता है और इसे `chartInstance.current` में स्टोर करता है।
2. क्लीनअप: जब कॉम्पोनेंट अनमाउंट होता है (या यदि `data` बदलता है, जिससे री-रन ट्रिगर होता है), तो कॉलबैक को पहले `null` के साथ कॉल किया जाता है। कोड जाँचता है कि क्या कोई चार्ट इंस्टेंस मौजूद है और यदि ऐसा है, तो इसके `destroy()` मेथड को कॉल करता है, जिससे मेमोरी लीक को रोका जा सकता है।
3. अपडेट: डिपेंडेंसी एरे में `data` को शामिल करके, हम यह सुनिश्चित करते हैं कि यदि चार्ट के डेटा को मौलिक रूप से बदलने की ज़रूरत है, तो पूरे चार्ट को साफ़ तौर पर नष्ट कर दिया जाता है और नए डेटा के साथ फिर से इनिशियलाइज़ किया जाता है। साधारण डेटा अपडेट के लिए, एक लाइब्रेरी एक `update()` मेथड ऑफ़र कर सकती है, जिसे एक अलग `useEffect` में संभाला जा सकता है।

परफ़ॉर्मेंस तुलना: ऑप्टिमाइज़ेशन *वास्तव में* कब मायने रखता है?

यथार्थवादी मानसिकता के साथ परफ़ॉर्मेंस तक पहुँचना ज़रूरी है। जबकि हर रेफ़ कॉलबैक को `useCallback` में रैप करना एक अच्छी आदत है, वास्तविक परफ़ॉर्मेंस इफ़ेक्ट कॉलबैक के अंदर किए जा रहे काम के आधार पर बहुत ज़्यादा भिन्न होता है।

नगण्य इफ़ेक्ट परिदृश्य

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

उदाहरण: ref={(node) => (myRef.current = node)}

ऐसे मामलों में, तकनीकी रूप से कम ऑप्टिमल होने पर भी, आप वास्तविक दुनिया के एप्लिकेशन में कभी भी परफ़ॉर्मेंस अंतर को मापने की संभावना नहीं रखते हैं। समय से पहले ऑप्टिमाइज़ेशन के जाल में न पड़ें।

महत्वपूर्ण इफ़ेक्ट परिदृश्य

जब आपका रेफ़ कॉलबैक निम्नलिखित में से कोई भी करता है तो आपको हमेशा useCallback का उपयोग करना चाहिए:

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

एक अच्छा नियम: यदि आपके रेफ़ कॉलबैक में एक साधारण असाइनमेंट से ज़्यादा कुछ है, तो इसे useCallback के साथ मेमोइज़ करें।

निष्कर्ष: प्रेडिक्टेबल और परफ़ॉर्मेंस कोड लिखना

रीऐक्ट का रेफ़ कॉलबैक एक शक्तिशाली टूल है जो DOM नोड्स और कॉम्पोनेंट इंस्टेंस पर फ़ाइन-ग्रेन्ड कंट्रोल प्रदान करता है। इसके लाइफ़सायकल को समझना—खास तौर पर क्लीनअप के दौरान जानबूझकर किया गया `null` कॉल—इसे प्रभावी ढंग से उपयोग करने की कुंजी है।

हमने सीखा है कि ref प्रोप के लिए एक इनलाइन फ़ंक्शन का उपयोग करने का सामान्य एंटी-पैटर्न हर रेंडर पर अनावश्यक और संभावित रूप से महंगी री-एक्सिक्यूशन की ओर ले जाता है। समाधान सुरुचिपूर्ण और मुहावरेदार रीऐक्ट है: useCallback हुक का उपयोग करके कॉलबैक फ़ंक्शन को स्थिर करें।

इस पैटर्न में महारत हासिल करके, आप:

• परफ़ॉर्मेंस बॉटलनेक को रोकें: प्रत्येक स्थिति परिवर्तन पर महंगे सेटअप और टियरडाउन लॉजिक से बचें।
• बग को खत्म करें: सुनिश्चित करें कि इवेंट लिस्नर और लाइब्रेरी इंस्टेंस को डुप्लिकेट या मेमोरी लीक के बिना साफ़ तौर पर प्रबंधित किया जाता है।
• प्रेडिक्टेबल कोड लिखें: ऐसे कॉम्पोनेंट बनाएँ जिनका रेफ़ लॉजिक बिल्कुल उसी तरह व्यवहार करता है जैसा कि अपेक्षित है, सिर्फ़ तभी चलता है जब कॉम्पोनेंट माउंट होता है, अनमाउंट होता है या जब इसकी खास डिपेंडेंसी बदलती हैं।

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