React.Component बनाम React.PureComponent


224

आधिकारिक डॉक्स प्रतिक्रिया राज्य है कि " React.PureComponent's shouldComponentUpdate()केवल उथले वस्तुओं तुलना", और इस के खिलाफ सलाह देता है, तो राज्य "गहरी" है।

इसे देखते हुए, क्या कोई कारण है कि किसी को React.PureComponentरिएक्ट घटक बनाते समय पसंद करना चाहिए ?

प्रश्न :

  • क्या इसका उपयोग करने में कोई प्रदर्शन प्रभाव है, React.Componentजिस पर हम विचार कर सकते हैं React.PureComponent?
  • मैं केवल उथले तुलना shouldComponentUpdate()के PureComponentप्रदर्शन का अनुमान लगा रहा हूं । अगर ऐसा है, तो कहा नहीं जा सकता है कि विधि का प्रयोग गहरी तुलना के लिए किया जाना चाहिए?
  • "इसके अलावा, React.PureComponentके shouldComponentUpdate()स्किप के पूरे घटक सबट्री के लिए अद्यतन सहारा" - यह है कि प्रोप परिवर्तनों को अनदेखा कर रहे हैं मतलब है?

प्रश्न इस माध्यम ब्लॉग में पढ़ने से उत्पन्न हुआ , अगर यह मदद करता है।


5
मुझे पता है कि आपको यह पोस्ट किए हुए कुछ महीने हो गए हैं, लेकिन मुझे लगा कि यह लेख मदद कर सकता है: 60devs.com/pure-component-in-react.html
MrOBrian

जवाबों:


283

के बीच प्रमुख अंतर React.PureComponentऔर React.Componentहै PureComponentएक करता है उथले तुलना स्थिति परिवर्तन पर। इसका मतलब यह है कि स्केलर मूल्यों की तुलना करते समय यह उनके मूल्यों की तुलना करता है, लेकिन वस्तुओं की तुलना करते समय यह केवल संदर्भों की तुलना करता है। यह ऐप के प्रदर्शन को बेहतर बनाने में मदद करता है।

React.PureComponentजब आप नीचे दी गई शर्तों में से किसी को संतुष्ट कर सकते हैं तो आपको जाना चाहिए ।

  • राज्य / प्रॉप्स एक अपरिवर्तनीय वस्तु होनी चाहिए
  • स्टेट / प्रॉप्स में पदानुक्रम नहीं होना चाहिए
  • forceUpdateडेटा बदलने पर आपको कॉल करना चाहिए

यदि आप उपयोग कर रहे हैं तो आपको React.PureComponentयह सुनिश्चित करना चाहिए कि सभी बच्चे घटक भी शुद्ध हों।

क्या React.component का उपयोग करने में कोई प्रदर्शन प्रभाव है जिसे हम React.PureComponent के लिए जाने पर विचार कर सकते हैं?

हां, यह आपके एप्लिकेशन प्रदर्शन को बढ़ाएगा (उथले तुलना के कारण)

मैं अनुमान लगा रहा हूँ कि Purecomponent का shouldComponentUpdate () केवल उथले तुलना करता है। यदि यह मामला है तो गहरी तुलना के लिए उपयोग की गई उक्त विधि नहीं हो सकती है?

आपने सही अनुमान लगाया। यदि आप ऊपर बताई गई किसी भी शर्त को पूरा करते हैं तो आप इसका उपयोग कर सकते हैं।

"इसके अलावा, React.PureComponent's shouldComponentUpdate () पूरे कंपोनेंट सबट्री के लिए प्रॉपर अपडेट्स को स्किप करता है" - क्या इसका मतलब यह है कि प्रोपर बदलावों को नजरअंदाज किया जाता है?

हां, प्रोपर बदलावों को नजरअंदाज कर दिया जाएगा अगर यह उथले तुलना में अंतर नहीं पा सके।


1
हाय @VimalrajSankar यहाँ मदद के लिए धन्यवाद। आप निम्न कथन का एक उदाहरण दे कृपया कर सकते हैं: It means that when comparing scalar values it compares their values, but when comparing objects it compares only references. It helps to improve the performance of the app.? धन्यवाद
इशान पटेल

1
@ Mr.Script मुझे उम्मीद है कि इससे stackoverflow.com/a/957602/2557900
vimal1083

3
State/Props should not have a hierarchyक्षमा करें, क्या आप थोड़ा सा समझा सकते हैं कि यहाँ क्या पदानुक्रम है?
सान लिव

1
@ SanyLiew का मतलब है कि राज्य और रंगमंच में केवल संख्या और तारों जैसे आदिम मूल्य शामिल होने चाहिए, लेकिन वस्तुओं के भीतर वस्तुओं (एक पदानुक्रम) नहीं।
jedmao

3
यदि राज्य / प्रॉप्स अपरिवर्तनीय वस्तु है, तो पदानुक्रम होना ठीक है और फिर भी PureComponent का उपयोग करें जब तक कि पदानुक्रम भी अपरिवर्तनीय ऑब्जेक्ट को बनाए रखता है, है ना?
सान एलवाईई

39

Componentऔर PureComponentएक अंतर है

PureComponentबिल्कुल वैसा ही है जैसे Componentकि यह shouldComponentUpdateआपके लिए विधि को संभालता है ।

जब प्रॉप्स या राज्य बदलते हैं, PureComponentतो प्रॉप्स और राज्य दोनों पर एक उथले तुलना करेंगे । Componentदूसरी ओर मौजूदा प्रॉपर और राज्य की तुलना बॉक्स से बाहर करने के लिए नहीं होगी। इस प्रकार, जब भी shouldComponentUpdateबुलाया जाता है , तब घटक डिफ़ॉल्ट रूप से फिर से प्रस्तुत करना होगा ।

उथला तुलना

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

स्रोत: https://codeburst.io/when-to-use-component-or-purecomponent-a60cfad01a81


React.Component => इसलिए अगर मैं एक ही घटक को कई बार एक ही सहारा के साथ फिर से प्रस्तुत करता हूं। यह बच्चे के रेंडर को ट्रिगर करेगा। कोई फर्क नहीं पड़ता कि प्रॉप्स बदले गए या नहीं
एहसान सरसर

23

मुख्य अंतर, जैसा कि मैं इसे देखता हूं, यह है कि घटक के रेंडरर्स हर बार अपने माता-पिता के रेंडरर्स की परवाह किए बिना, चाहे घटक के प्रॉप्स और राज्य बदल गए हों।

एक शुद्ध घटक, दूसरी ओर, अपने माता-पिता के रेंडरर्स को तब तक रेंडर नहीं करेगा, जब तक कि शुद्ध घटक के प्रॉप्स (या राज्य) बदल नहीं गए हों।

उदाहरण के लिए, हम कहते हैं कि हमारे पास तीन-स्तरीय पदानुक्रम वाला एक घटक वृक्ष है: माता-पिता, बच्चे और पोते।

जब माता-पिता की प्रॉप्स को एक तरह से बदल दिया जाता है, केवल एक बच्चे के प्रॉप्स को बदल दिया जाता है, तो:

  • यदि सभी घटक नियमित घटक हैं, तो संपूर्ण घटक पेड़ रेंडर करेगा
  • यदि सभी बच्चे और पोते शुद्ध घटक हैं, तो केवल एक बच्चा ही रेंडर करेगा, और एक या उसके सभी पोते, जो इस बात पर निर्भर करते हैं कि उनके प्रॉप्स बदले जाते हैं या नहीं। यदि इस घटक पेड़ में कई घटक हैं, तो इसका मतलब हो सकता है कि एक महत्वपूर्ण प्रदर्शन को बढ़ावा देना।

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.