अंतिम प्रतिक्रिया घटक

रिएक्ट इकोसिस्टम के बारे में मुझे जो पसंद है वह यह है कि कई फैसलों के पीछे IDEA का हाथ है। विभिन्न लेखक मौजूदा आदेश के समर्थन में विभिन्न लेख लिखते हैं और समझाते हैं कि सब कुछ "सही" क्यों है, इसलिए हर कोई समझता है कि पार्टी सही रास्ते पर है।

कुछ समय बाद, IDEA थोड़ा बदल जाता है, और सब कुछ शुरू से शुरू होता है।

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

समस्या

समस्या बहुत सरल है - इकाई परीक्षण। हाल ही में, एकीकरण परीक्षणों की दिशा में कुछ आंदोलन हुए हैं - ठीक है, आप जानते हैं "परीक्षण लिखें। बहुत अधिक नहीं। ज्यादातर एकीकरण।" । यह एक बुरा विचार नहीं है, और यदि समय कम है (और परीक्षणों की विशेष आवश्यकता नहीं है) - यह वही है जो आपको करने की आवश्यकता है। बस यह बताएं कि यह धुआं परीक्षण करता है - यह सत्यापित करने के लिए कि कुछ भी विस्फोट नहीं होता है।

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

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

अलगाव इकाई परीक्षण में प्रमुख बिंदुओं में से एक है, और यही कारण है कि इकाई परीक्षण पसंद नहीं करते हैं। उन्हें विभिन्न कारणों से यह पसंद नहीं है:

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

व्यक्तिगत रूप से, मुझे यहां कोई समस्या नहीं दिख रही है। पहले पैराग्राफ में, निश्चित रूप से, आप एकीकरण परीक्षणों की सिफारिश कर सकते हैं, उन्हें इसके लिए आविष्कार किया गया है - यह जांचने के लिए कि पूर्व-परीक्षण किए गए घटकों को सही तरीके से कैसे इकट्ठा किया गया है। आप npm संकुल पर भरोसा करते हैं जो परीक्षण करता है, ज़ाहिर है, केवल स्वयं, और स्वयं आपके आवेदन के हिस्से के रूप में नहीं। आपके "घटक" कैसे "आपके" पैकेज से भिन्न होते हैं?

दूसरे पैराग्राफ के साथ, सब कुछ थोड़ा और अधिक जटिल है। और यह लेख इस बिंदु के बारे में ठीक से होगा (और इससे पहले कि सब कुछ ऐसा था - एक परिचय) - एक "इकाई" इकाई को कैसे परीक्षण योग्य बनाया जाए, इसके बारे में ।

फूट डालो और जीतो

प्रतिक्रिया घटकों को "कंटेनर" और "प्रस्तुति" में अलग करने का विचार नया नहीं है, अच्छी तरह से वर्णित है, और पहले से ही थोड़ा पुराना होने में कामयाब रहा है। यदि हम डैन अब्रामोव के एक लेख के आधार पर (डेवलपर्स का 99% क्या करते हैं) प्रस्तुत करते हैं, तो प्रस्तुति घटक:

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

खैर, कंटेनर सभी तर्क, डेटा तक सभी पहुंच और सिद्धांत रूप में संपूर्ण अनुप्रयोग हैं।

एक आदर्श दुनिया में, कंटेनर ट्रंक हैं, और प्रस्तुति घटक पत्तियां हैं।

डैन की परिभाषा में दो प्रमुख बिंदु हैं: "एप्लिकेशन स्वतंत्र" , जो लगभग "यूनिट" की एक अकादमिक परिभाषा है, और * "मई में अन्य प्रस्तुति घटक और कंटेनर ** " * शामिल हो सकते हैं, जहां ये सितारे विशेष रूप से दिलचस्प हैं।

(मुक्त अनुवाद) ** मेरे लेख के शुरुआती संस्करणों में, मैंने (डान) कहा था कि प्रस्तुति घटकों में केवल अन्य प्रस्तुति घटक शामिल होने चाहिए। मैं अब और नहीं सोचता। घटक का प्रकार विवरण है और समय के साथ बदल सकता है। सामान्य तौर पर, इसे साझा न करें और सबकुछ ठीक हो जाएगा।

आइए याद करें कि इसके बाद क्या होता है:

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

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

नतीजतन, आपको उथले का उपयोग करना होगा, जो डिजाइन द्वारा सभी हानिकारक (और अप्रत्याशित) दुष्प्रभावों को समाप्त करता है। यहाँ लेख से एक सरल उदाहरण है "मैं हमेशा उथले का उपयोग क्यों करता हूं"

कल्पना करें कि टूलटिप "?", जब क्लिक किया जाता है, तो टाइप ही दिखाया जाएगा।

 import Tooltip from 'react-cool-tooltip'; const MyComponent = () => { <Tooltip> hint: {veryImportantTextYouHaveToTest} </Tooltip> } 

इसका परीक्षण कैसे करें? माउंट + क्लिक + जांचें कि क्या दिखाई दे रहा है। यह एक एकीकरण परीक्षण है, एक इकाई नहीं है, और सवाल यह है कि आपके लिए "विदेशी" घटक पर कैसे क्लिक करें। उथले के साथ कोई समस्या नहीं है, क्योंकि कोई दिमाग और "विदेशी घटक" खुद नहीं हैं। लेकिन यहां दिमाग हैं, क्योंकि टूलटिप एक कंटेनर है, जबकि MyComponent व्यावहारिक रूप से प्रस्तुति है।

 jest.mock('react-cool-tooltip', {default: ({children}) => childlren}); 

लेकिन अगर आप कूल-टूलटिप प्रतिक्रिया करते हैं, तो परीक्षण के साथ कोई समस्या नहीं होगी। "घटक" तेजी से बहुत कमज़ोर हो गया है, बहुत कम, बहुत अधिक परिमित ।

अंतिम घटक

• एक प्रसिद्ध आकार के साथ एक घटक, जिसमें अन्य, पहले से ज्ञात, अंतिम घटक शामिल हो सकते हैं, या उन्हें बिल्कुल भी शामिल नहीं कर सकते हैं।
• अन्य कंटेनरों में नहीं होता है, क्योंकि उनमें एक अनियंत्रित राज्य होता है और "वृद्धि" आकार होता है, अर्थात। वर्तमान घटक को अनंत बनाएं।
• अन्यथा यह एक नियमित प्रस्तुति घटक है। वास्तव में, जैसा कि डैन के लेख के पहले संस्करण में वर्णित है।

अंतिम घटक एक गियर है जो एक बड़े तंत्र से निकाला जाता है।

पूरा सवाल यह है कि इसे कैसे निकाला जाए।

समाधान 1 - DI

मेरा पसंदीदा डिपेंडेंसी इंजेक्शन है। डैन उससे भी प्यार करता है । सामान्य तौर पर, यह DI नहीं है, लेकिन "स्लॉट" है। संक्षेप में - प्रस्तुति के अंदर कंटेनरों का उपयोग करने की आवश्यकता नहीं है - उन्हें वहां इंजेक्ट करने की आवश्यकता है। और परीक्षणों में इसे कुछ और इंजेक्ट करना संभव होगा।

 //    mount     const PageChrome = ({children, aside}) => ( <section> <aside>{aside}</aside> {children} </section> ); //     shallow,       //     mount ? , ,   wiring? const PageChromeContainer = () => ( <PageChrome aside={<ASideContainer />}> <Page /> </PageChrome> ); 

यह वास्तव में मामला है जब "कंटेनर ट्रंक हैं, और प्रस्तुति घटक पत्ते हैं"

समाधान 2 - सीमाएँ

DI अक्सर शांत हो सकते हैं। शायद अब% उपयोगकर्ता नाम% सोचता है कि यह वर्तमान कोड आधार पर कैसे लागू किया जा सकता है, और समाधान का आविष्कार नहीं किया गया है ...

ऐसे मामलों में, सीमाएं आपको बचाएंगी ।

 const Boundary = ({children}) => ( process.env.NODE_ENV === 'test' ? null : children // //  jest.mock ); const PageChrome = () => ( <section> <aside><Boundary><ASideContainer /></Boundary></aside> <Boundary><Page /></Boundary> </section> ); 

यहां, "स्लॉट्स" के बजाय, सभी "संक्रमण बिंदु" बस सीमा में बदल जाते हैं, जो परीक्षणों के दौरान कुछ भी प्रस्तुत करेगा। घोषणात्मक रूप से पर्याप्त है, और वास्तव में आपको "गियर बाहर निकालने" की आवश्यकता है।

समाधान 3 - टीयर

सीमाएँ थोड़ी खुरदरी हो सकती हैं, और लेयर के बारे में थोड़ा सा ज्ञान जोड़कर उन्हें थोड़ा और आसान बनाना आसान हो सकता है।

 const checkTier = tier => tier === currentTier; const withTier = tier => WrapperComponent => (props) => ( (process.env.NODE_ENV !== 'test' || checkTier(tier)) && <WrapperComponent{...props} /> ); const PageChrome = () => ( <section> <aside><ASideContainer /></aside> <Page /> </section> ); const ASideContainer = withTier('UI')(...) const Page = withTier('Page')(...) const PageChromeContainer = withTier('UI')(PageChrome); 

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

और कुछ भी इन सीमाओं को किसी भी तरह से अलग करने से रोकता है।

समाधान 4 - अलग चिंताएं

यदि समाधान (परिभाषा द्वारा) संस्थाओं के अलगाव में निहित है - अगर हम उन्हें लेते हैं और उन्हें अलग करते हैं तो क्या होगा?

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

क्या होगा अगर रनटाइम में राइट एक नाम के आधार पर संस्थाओं के बीच एक रेखा खींचता है?

 const PageChrome = () => ( <section> <aside><ASideContainer /></aside> <Page /> </section> ); // remove all components matching react-redux pattern reactRemock.mock(/Connect\(\w\)/) // all any other container reactRemock.mock(/Container/) 

परीक्षण में प्लस एक लाइन, और प्रतिक्रिया-रिमॉक उन सभी कंटेनरों को हटा देगा जो परीक्षणों में हस्तक्षेप कर सकते हैं।

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

 import {createElement, remock} from 'react-remock'; //  "" const ContainerCondition = React.createContext(true); reactRemock.mock(/Connect\(\w\)/, (type, props, children) => ( <ContainerCondition.Consumer> { opened => ( opened ? ( // ""     <ContainerCondition.Provider value={false}> {createElement(type, props, ...children)} <ContainerCondition.Provider> ) // "" : null )} </ContainerCondition.Consumer> ) 

फिर से - लाइनों और गियर के एक जोड़े को हटा दिया।

कुल मिलाकर

पिछले एक साल में, रिएक्ट घटकों का परीक्षण अधिक जटिल हो गया है, विशेष रूप से माउंट के लिए - आपको सभी 10 प्रोवाइडर्स, कॉन्टेक्ट्स को अधिलेखित करने की आवश्यकता है, और सही शैली में सही घटक का परीक्षण करने के लिए कठिन और कठिन हो रहा है - खींचने के लिए बहुत अधिक रस्सियां ​​हैं।
कोई उगलता है और उथली दुनिया में चला जाता है। किसी ने यूनिट परीक्षणों में अपना हाथ लहराया और सब कुछ सरू को स्थानांतरित कर दिया (जैसे चलना चलना!)।

कोई और प्रतिक्रिया पर उंगली उठाता है, कहता है कि ये बीजीय प्रभाव हैं और आप जो चाहें कर सकते हैं। उपरोक्त सभी उदाहरण अनिवार्य रूप से इन बीजीय प्रभावों और मोक्स का उपयोग हैं। मेरे और DI के लिए ये मोकी हैं।

पुनश्च: इस पोस्ट को रिएक्ट / आरएफसी में टिप्पणियों के जवाब के रूप में इस तथ्य के बारे में लिखा गया था कि रिएक्ट टीम ने सब कुछ तोड़ दिया, और सभी पॉलिमर भी
PPS: यह पोस्ट वास्तव में दूसरे का बहुत ही मुफ्त अनुवाद है
PPPS: सामान्य तौर पर, वास्तविक अलगाव के लिए, rewiremock को देखें