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

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

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

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

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

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

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

चलो Avatar घटक के बारे में बात करते हैं।

 <Avatar image="simons-cat.png" /> 

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

आइए प्रोप size ( size के लिए प्रोप) जोड़ें।

हम डेवलपर को मनमानी चौड़ाई और ऊंचाइयों को निर्दिष्ट करने की क्षमता नहीं देना चाहते हैं, इसके बजाय, हम डेवलपर को कई संभावित आकार देना चाहते हैं।

 <Avatar size="xsmall" image="simons-cat.png" /> <Avatar size="small" image="simons-cat.png" /> <Avatar size="medium" image="simons-cat.png" /> <Avatar size="large" image="simons-cat.png" /> <Avatar size="xlarge" image="simons-cat.png" /> 

ब्रह्मांड में , हमारे पास अभी भी ऐप्स के लिए अवतार हैं। हम चाहते हैं कि वे थोड़ा अलग दिखें - एक सर्कल के बजाय एक गोल वर्ग।

एक अच्छा एपीआई बनाने का एक हिस्सा डेवलपर्स को डिजाइन के बजाय डेटा के बारे में सोचने की क्षमता देना है - डिजाइन पहले से ही घटक में होना चाहिए

हम एक और प्रोप जोड़ सकते हैं जो दो प्रकार के अवतारों के बीच अंतर करता है। एक छोटा सा सहारा चोट नहीं कर सकता, है ना?

 <Avatar type="user" image="simons-cat.png" /> <Avatar type="app" image="firebase.png" /> 

अच्छा लग रहा है, है ना?

और हां, हमें एप्लिकेशन अवतार के लिए बहु-आकार का समर्थन मिलता है, क्योंकि यह एक ही घटक है। सामान्य तौर पर, हमें इसकी आवश्यकता नहीं है, लेकिन क्यों नहीं, क्योंकि इसने हमें कुछ भी खर्च नहीं किया है

 <Avatar type="app" size="xsmall" image="firebase.png" /> <Avatar type="app" size="small" image="firebase.png" /> <Avatar type="app" size="medium" image="firebase.png" /> <Avatar type="app" size="large" image="firebase.png" /> <Avatar type="app" size="xlarge" image="firebase.png" /> 

चलो इस बारे में बात करते हैं कि डेवलपर अपने आवेदन में वास्तव में इस घटक का उपयोग कैसे करेगा। उपयोगकर्ता जानकारी शायद एपीआई से आती है और इसमें अवतार का URL होता है। डेवलपर प्रॉपर का उपयोग करके Avatar घटक को यह जानकारी देगा।

और अगर उपयोगकर्ता ने अभी तक अवतार अपलोड नहीं किया है, तो हम डिफ़ॉल्ट मान दिखाना चाहते हैं, वही एप्लिकेशन लोगो के लिए जाता है।

 <Avatar type="user" image={props.user.avatar} /> <Avatar type="user" image={missing} /> <Avatar type="app" image={props.app.logo} /> <Avatar type="app" image={missing} /> 

डिफ़ॉल्ट छवि पहले से ही घटक में शामिल है, इसलिए हम डेवलपर को डिफ़ॉल्ट छवि छवि के लिए नहीं पूछते हैं।

यह एक अच्छी गिरावट है, लेकिन हम और अधिक कर सकते हैं।

हम यूनिक बैकग्राउंड वाले यूजरनेम के शुरुआती अक्षर दिखा सकते हैं (जीमेल ने इस टेम्प्लेट को लोकप्रिय बना दिया है, यह लोगों को जल्दी से अलग करने में मदद करता है)

 <Avatar type="user" image={props.user.avatar} /> <Avatar type="user" image={missing} /> <Avatar type="user" initials={props.user.intials} image={missing} /> <Avatar type="app" image={props.app.logo} /> <Avatar type="app" image={missing} /> <Avatar type="app" icon={props.app.type} image={missing} /> 

आइए उन सभी प्रॉप्स को देखें जो हमारे घटक का समर्थन करते हैं:

हमने एक सरल अवतार घटक के साथ शुरुआत की, लेकिन अब यह इन सभी सहारा और व्यवहार का समर्थन करता है!

जब आप एक घटक को देखते हैं जो कई प्रॉप्स का समर्थन करता है, तो यह संभवतः बहुत सी चीजें करने की कोशिश कर रहा है। आपने अभी Apropcalypse बनाया है।

इस अवधारणा को जेन क्रेइटन ने गढ़ा।

हम अपने Avatar घटक को उपयोगकर्ताओं के लिए और अनुप्रयोगों के लिए काम करने की कोशिश कर रहे हैं, और एक ही समय में विभिन्न आकारों और कमबैक व्यवहार के लिए विभिन्न विकल्पों के साथ काम करते हैं।

यह अजीब संयोजनों के लिए भी अनुमति देता है जो उपयोग के लिए अनुशंसित नहीं हैं, जैसे कि बैकअप टेक्स्ट एप्लिकेशन अवतार। याद रखें, यह टिप # 1 था - परस्पर विरोधी प्रॉप्स न बनाएं ( प्रतिक्रिया घटकों के लिए एपीआई लिखना, भाग 1: परस्पर विरोधी प्रॉप्स न बनाएं )!

ठीक है, हम इससे कैसे निपटेंगे? दो अलग-अलग घटक बनाएं।

परिषद:

मौजूदा घटक में प्रॉपर और अतिरिक्त तर्क जोड़ने के बजाय एक नया घटक बनाने से डरो मत।

सबसे पहले, यहाँ एपीआई दो अलग-अलग अवतार घटकों के लिए कैसा दिखेगा:

 <UserAvatar size="large" image="simons-cat.png" /> <UserAvatar size="large" image="" /> <UserAvatar size="large" fallback="LA" image="" /> <AppAvatar image="firebase.png" /> <AppAvatar image="" /> <AppAvatar fallback="database" image="" /> 

इस एपीआई में कई बातें ध्यान देने योग्य हैं:

1. हम AppAvatar में अनावश्यक विशेषताओं, जैसे size को निकालने में सक्षम थे।
2. हमने दो घटकों के लिए एक ही fallback नाम (फ़ॉलबैक) को बनाए रखते हुए अपने एपीआई के आकार को कम कर दिया ।
   इस श्रृंखला में टिप नंबर 2 याद है? हम चाहते हैं कि डेवलपर्स व्यवहार ( fallback ) के बारे में सोचें , न कि बातचीत / कार्यान्वयन (प्रारंभिक या आइकन) के बारे में । यह डेवलपर्स को तेजी से घटकों का उपयोग करने के लिए एपीआई और तरीके सीखने में मदद करता है।
3. हम किसी भी परस्पर विरोधी संकट से भी बच सकते हैं।
4. अंत में, हमने प्रॉप्स की संख्या कम कर दी। प्रॉप्स टेबल को देखें, तो यह बहुत साफ हो गया है:

userAvatar:

AppAvatar:

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

चलो कार्यान्वयन के बारे में बात करते हैं। यह एक BaseAvatar घटक बनाने के लिए BaseAvatar है जो UserAvatar और UserAvatar दोनों का उपयोग करेगा, जबकि कुछ UserAvatar अवरुद्ध हो जाएंगे।

 function UserAvatar(props) { return ( <BaseAvatar image={props.image} type="user" initials={props.fallback} /> ) } render(<UserAvatar fallback="LA" />) 

और यह बिल्कुल भी बुरा विचार नहीं है। लेकिन शुरुआत में यह अनुमान लगाना बहुत मुश्किल है कि हमें क्या चाहिए। हम भविष्य की मांगों का खराब अनुमान लगाते हैं।

दो अलग-अलग घटकों से शुरू करें, और जैसा कि आप उन्हें विकसित करते हैं, आप समान पैटर्न देखना शुरू कर सकते हैं और एक अच्छा अमूर्त पा सकते हैं। गलत अमूर्तता की तुलना में अमूर्तता का अभाव बहुत बेहतर है।

डुप्लिकेटेशन गलत अमूर्त से बेहतर है - सैंडी मेट्ज़

अपने कोड पर वापस जाएं और उस घटक को ढूंढें जो बहुत सारे प्रॉपर लेता है और देखें कि क्या आप इसे कई घटकों में तोड़कर सरल बना सकते हैं।

आगे के अध्ययन के लिए:

1. जेन क्रेइटन का एक व्याख्यान , जहां वह एप्रोपैकलिप्स के बारे में बात करता है
2. डुप्लिकेट और अमूर्त पर सैंडी मेट्ज़ व्याख्यान