प्रतिक्रिया घटकों के लिए एपीआई लिखना, भाग 3: सहारा का क्रम महत्वपूर्ण है

प्रतिक्रिया घटकों के लिए एक एपीआई लिखना, भाग 1: परस्पर विरोधी सहारा न बनाएं

प्रतिक्रिया घटकों के लिए एक एपीआई लिखना, भाग 2: व्यवहार को नाम दें, सहभागिता नहीं

प्रतिक्रिया घटकों के लिए एपीआई लिखना, भाग 3: सहारा का क्रम महत्वपूर्ण है

रिएक्ट कंपोनेंट्स के लिए एपीआई लिखना, भाग 4: एप्रोपैकलिप्स से सावधान रहें!

प्रतिक्रिया घटकों के लिए एक एपीआई लिखना, भाग 5: बस उपयोग संरचना

हम प्रतिक्रियाशील घटकों के लिए एपीआई लिखते हैं, भाग 6: हम घटकों के बीच संचार बनाते हैं

आइए एक सरल प्रतिक्रिया घटक से शुरू करें जो एक लंगर टैग प्रदर्शित करता है:

<Link href="sid.studio">Click me</Link> //   : <a href="sid.studio" class="link">Click me</a> 

यहाँ घटक कोड कैसा दिखता है:

 const Link = props => { return ( <a href={props.href} className="link"> {props.children} </a> ) } 

हम HTML एट्रिब्यूट्स को भी एलिमेंट में जोड़ना चाहते हैं, जैसे कि id , target , title , data-attr , आदि।

चूंकि बहुत सी HTML विशेषताएँ हैं, हम केवल सभी प्रॉप्स को पास कर सकते हैं और जिन्हें हमें ज़रूरत है उन्हें जोड़ सकते हैं (जैसे className )

(नोट: आपको उन विशेषताओं को पारित नहीं करना चाहिए जो आप इस घटक के लिए आए थे जो HTML विनिर्देश में नहीं हैं)

इस स्थिति में, आप केवल className उपयोग कर सकते हैं

 const Link = props => { /*    (spread ),     ( ) */ return <a {...props} className="link" /> } 

बस यहीं से दिलचस्प हो जाता है।

जब कोई किसी id या target पार करता है तो सब कुछ ठीक लगता है:

 <Link href="sid.studio" id="my-link">Click me</Link> //   : <a href="sid.studio" id="my-link" class="link">Click me</a> 

लेकिन तब क्या होता है जब कोई className गुजरता है?

 <Link href="sid.studio" className="red-link">Click me</Link> //   : <a href="sid.studio" class="link">Click me</a> 

खैर, कुछ नहीं हुआ। रिऐक्ट ने कस्टम क्लास को पूरी तरह से नजरअंदाज कर दिया। चलो समारोह में वापस आते हैं:

 const Link = props => { return <a {...props} className="link" /> } 

ठीक है, आइए कल्पना करें कि यह कैसे ...props संकलन करता है, उपरोक्त कोड इसके बराबर है:

 const Link = props => { return ( <a href="sid.studio" className="red-link" className="link" > Click me </a> ) } 

संघर्ष देखें? दो className । रिएक्ट इसे कैसे संभालता है?

खैर, रिएक्ट कुछ नहीं करता। कोलाहल करता है!

याद रखें कि React.createElement " React.createElement " का उत्पादन करता है। प्रॉप्स को एक वस्तु में परिवर्तित किया जाता है और एक तर्क के रूप में पारित किया जाता है। ऑब्जेक्ट डुप्लिकेट कुंजियों का समर्थन नहीं करते हैं, इसलिए दूसरा className पहले को अधिलेखित कर देगा।

 const Link = props => { return React.createElement( 'a', { className: 'link', href: 'sid.studio' }, 'Click me' ) } 

ठीक है, अब जब हम समस्या के बारे में जानते हैं, तो हम इसे कैसे हल कर सकते हैं?

यह समझना उपयोगी है कि यह त्रुटि एक नाम संघर्ष के कारण हुई, और यह किसी भी प्रोप के साथ हो सकता है, और केवल className साथ नहीं। इसलिए निर्णय उस व्यवहार पर निर्भर करता है जिसे आप लागू करना चाहते हैं।

तीन संभावित परिदृश्य हैं:

1. हमारे घटक का उपयोग करने वाला एक डेवलपर डिफ़ॉल्ट प्रोप वैल्यू को ओवरराइड करने में सक्षम होना चाहिए ।
2. हम डेवलपर को कुछ प्रॉपर बदलने नहीं देना चाहते हैं
3. डिफ़ॉल्ट मान को बनाए रखते हुए डेवलपर को मूल्यों को जोड़ने में सक्षम होना चाहिए ।

आइए एक बार में उन्हें अलग करें।

1. हमारे घटक का उपयोग करने वाले डेवलपर को डिफ़ॉल्ट प्रोप मूल्य को ओवरराइड करने में सक्षम होना चाहिए

यह वह व्यवहार है जो आप आमतौर पर अन्य विशेषताओं से उम्मीद करते हैं - id , title , आदि।

हम अक्सर ब्रह्मांड में test id सेटिंग देखते हैं (जिस डिज़ाइन सिस्टम पर मैं काम कर रहा हूं)। प्रत्येक घटक एक डिफ़ॉल्ट data-test-id प्राप्त करता है, कभी data-test-id कभी डेवलपर्स इसके बजाय विशिष्ट उपयोग को इंगित करने के लिए अपने स्वयं के परीक्षण पहचानकर्ता को जोड़ना चाहते हैं।

यहाँ एक ऐसा उपयोग मामला है:

 const Breadcrumb = () => ( <div className="breadcrumb" data-test-id="breadcrumb"> <Link data-test-id="breadcrumb.link">Home</Link> <Link data-test-id="breadcrumb.link">Parent</Link> <Link data-test-id="breadcrumb.link">Page</Link> </div> ) 

Breadcrumb लिंक का उपयोग करता है, लेकिन आप इसे अधिक विशिष्ट data-test-id साथ परीक्षणों में उपयोग करने में सक्षम होना चाहते हैं। इसमें दोष है।

ज्यादातर मामलों में, कस्टम प्रॉप्स को डिफ़ॉल्ट प्रॉपर से अधिक पूर्वता लेना चाहिए।

व्यवहार में, इसका मतलब है कि डिफ़ॉल्ट प्रॉप्स को पहले जाना चाहिए, और फिर उन्हें ओवरराइड करने के लिए {...props} ।

 const Link = props => { return ( <a className="link" data-test-id="link" {...props} /> ) } 

याद रखें कि data-test-id (प्रॉप्स से) की दूसरी उपस्थिति पहले (डिफ़ॉल्ट रूप से) को ओवरराइड करेगी। इसलिए, जब कोई डेवलपर अपने स्वयं के data-test-id या className , तो वह उस डिफ़ॉल्ट को ओवरराइड करता है जो डिफ़ॉल्ट रूप से था:

 1. <Link href="sid.studio">Click me</Link> 2. <Link href="sid.studio" data-test-id="breadcrumb.link">Click me</Link> //   : 1. <a class="link" href="sid.studio" data-test-id="link">Click me</a> 2. <a class="link" href="sid.studio" data-test-id="breadcrumb.link">Click me</a> 

हम className साथ भी ऐसा कर सकते हैं:

 <Link href="sid.studio" className="red-link">Click me</Link> //   : <a href="sid.studio" class="red-link" data-test-id="link">Click me</a> 

यह अजीब लग रहा है, मुझे यकीन नहीं है कि हमें इसकी अनुमति देनी चाहिए! इसके बारे में आगे बात करते हैं।

2. हम डेवलपर को कुछ प्रॉपर बदलने की अनुमति नहीं देना चाहते हैं

मान लें कि हम नहीं चाहते हैं कि डेवलपर्स उपस्थिति ( className माध्यम से) को बदल className , लेकिन हमें इस बात से कोई आपत्ति नहीं है कि वे अन्य प्रॉप्स, जैसे id , data-test-id इत्यादि को बदलते हैं।

हम अपनी विशेषताओं का आदेश देकर ऐसा कर सकते हैं:

 const Link = props => { return ( <a data-test-id="link" {...props} className="link" /> ) } 

याद रखें कि दाईं ओर की विशेषता बाईं ओर की विशेषता को ओवरराइड करेगी। इस प्रकार, {...props} से पहले की सभी चीजों को फिर से परिभाषित किया जा सकता है, लेकिन इसके बाद की हर चीज को फिर से परिभाषित नहीं किया जा सकता है।

डेवलपर्स के काम को सरल बनाने के लिए, आप एक चेतावनी प्रदर्शित कर सकते हैं जिसे आप अपना className निर्दिष्ट नहीं कर सकते हैं।

मैं इसके लिए अपना स्वयं का प्रकार जांच प्रॉप बनाना पसंद करता हूं:

 Link.PropTypes = { className: function(props) { if (props.className) { return new Error( `  className  Link,      ` ) } } } 

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

अब, जब डेवलपर className को ओवरराइड करने की कोशिश करता है, तो यह काम नहीं करेगा, और डेवलपर को एक चेतावनी मिलेगी।

 <Link href="sid.studio" className="red-link">Click me</Link> //   : <a href="sid.studio" class="link">Click me</a> 

 :   :   className  Link,       

ईमानदारी से, मुझे इस टेम्पलेट का उपयोग केवल एक या दो बार करना था। आमतौर पर आप अपने घटक का उपयोग करके डेवलपर पर भरोसा करते हैं।

जो हमें साझा करने के लिए लाता है।

3. डेवलपर को डिफ़ॉल्ट मान बनाए रखते हुए मूल्यों को जोड़ने में सक्षम होना चाहिए

यह शायद कक्षाओं के लिए सबसे आम उपयोग का मामला है।

 <Link href="sid.studio" className="underline">Click me</Link> //   : <a href="sid.studio" class="link underline">Click me</a> 

कार्यान्वयन इस तरह दिखता है:

 const Link = props => { /*  className   */ const { className, otherProps } = props /*     */ const classes = 'link ' + className return ( <a data-test-id="link" className={classes} {...otherProps} /*     */ /> ) } 

यह टेम्पलेट ईवेंट हैंडलर (उदाहरण के लिए, onClick ) को एक घटक के लिए स्वीकार करने के लिए भी उपयोगी है जो पहले से ही उनके पास है।

 <Switch onClick={value => console.log(value)} /> 

यहाँ इस घटक का कार्यान्वयन कैसा दिखता है:

 class Switch extends React.Component { state = { enabled: false } onToggle = event => { /*      */ this.setState({ enabled: !this.state.enabled }) /*       */ if (typeof this.props.onClick === 'function') { this.props.onClick(event, this.state.enabled) } } render() { /*        ️ */ return <div class="toggler" onClick={this.onToggle} /> } } 

इवेंट हैंडलर में नाम की गड़बड़ी से बचने का एक और तरीका है; मैंने इसे राइटिंग कंपोनेंट्स के लिए राइटिंग एपीआई में वर्णित किया , भाग 2: व्यवहार को नाम दें, बातचीत के तरीके नहीं ।

प्रत्येक परिदृश्य के लिए, आप विभिन्न तरीकों का उपयोग कर सकते हैं।

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