संरचित प्रतिक्रिया अनुप्रयोग

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

रिएक्ट की सबसे सुखद विशेषताओं में से एक यह है कि यह पुस्तकालय डेवलपर को परियोजना की संरचना के बारे में कुछ सम्मेलनों का सख्ती से पालन करने के लिए मजबूर नहीं करता है। इसमें से अधिकांश प्रोग्रामर के विवेक पर रहता है। यह दृष्टिकोण उस से अलग है, कहते हैं, Ember.js या कोणीय ढांचे में अपनाया गया है। वे डेवलपर्स को अधिक मानक सुविधाएं देते हैं। ये ढांचे फाइलों और घटकों के नामकरण के लिए परियोजनाओं और नियमों की संरचना के बारे में सम्मेलनों के लिए प्रदान करते हैं।



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

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

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

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

दरअसल, अब, आगे की हलचल के बिना, मैं आपको रिएक्ट एप्लिकेशन को संरचित करने के बारे में अपनी कहानी पेश करता हूं।

नियमों के बारे में बहुत ज्यादा चिंता मत करो।

शायद आप यह तय करते हैं कि नियमों के बारे में बहुत अधिक चिंता करने की सिफारिश हमारी बातचीत की शुरुआत में अजीब लगती है। लेकिन यह वही है जो मेरा मतलब है जब मैं कहता हूं कि प्रोग्रामर नियमों को देखने के मामले में मुख्य गलती यह है कि प्रोग्रामर नियमों को बहुत अधिक महत्व देते हैं। यह एक नई परियोजना पर काम की शुरुआत में विशेष रूप से सच है। पहली index.jsx के निर्माण के समय index.jsx जानना असंभव है कि इस परियोजना के लिए सबसे अच्छा क्या है। जैसा कि परियोजना विकसित होती है, आप स्वाभाविक रूप से किसी प्रकार की फ़ाइल और फ़ोल्डर संरचना में आएंगे, जो इस परियोजना के लिए काफी अच्छा होने की संभावना है। यदि कार्य की निरंतरता के दौरान यह पता चलता है कि मौजूदा संरचना कुछ असफल है, तो इसमें सुधार किया जा सकता है।

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

महत्वपूर्ण घटक अलग फ़ोल्डर में स्थित हैं

फ़ोल्डर में घटक फ़ाइलों को रखने के लिए दृष्टिकोण जो मैं आया था कि उन घटकों को "महत्वपूर्ण", "मूल", "मुख्य" माना जा सकता है जो अनुप्रयोग संदर्भ में अलग फ़ोल्डर में रखे गए हैं। ये फ़ोल्डर, बदले में, components फ़ोल्डर में स्थित हैं। उदाहरण के लिए, यदि हम एक इलेक्ट्रॉनिक स्टोर के लिए एक आवेदन के बारे में बात कर रहे हैं, तो <Product> का वर्णन करने के लिए उपयोग किए जाने वाले <Product> घटक को एक समान घटक के रूप में पहचाना जा सकता है। यहाँ मेरा मतलब है:

 - src/  - components/    - product/      - product.jsx      - product-price.jsx    - navigation/      - navigation.jsx    - checkout-flow/      - checkout-flow.jsx 

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

यद्यपि मैं परियोजना में एक निश्चित फ़ोल्डर संरचना की उपस्थिति का समर्थक हूं, लेकिन मेरा मानना ​​है कि सबसे महत्वपूर्ण बात अच्छे फ़ाइल नामों का चयन है। फ़ोल्डर स्वयं कम महत्वपूर्ण नहीं हैं।

उपकेंद्रों के लिए सबफ़ोल्डर का उपयोग करना

उपरोक्त दृष्टिकोण की कमियों में से एक यह है कि इसके उपयोग से "बेसिक" घटकों के फ़ोल्डर की उपस्थिति हो सकती है जिसमें बहुत सारी फाइलें होती हैं। उदाहरण के लिए, <Product> घटक पर विचार करें। सीएसएस फाइलें इसके साथ जुड़ी होंगी (हम बाद में उनके बारे में बात करेंगे), परीक्षण फाइलें, कई उप-कंप्यूटर और, संभवतः, अन्य संसाधन - जैसे चित्र और एसवीजी आइकन। "परिवर्धन" की यह सूची सीमित नहीं है। यह सब "बेस" घटक के समान फ़ोल्डर में गिर जाएगा।

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

हालाँकि, यदि आप अपनी परियोजना को अधिक व्यापक संरचना के लिए पसंद करते हैं, तो अपने स्वयं के फ़ोल्डरों में सबकुछ स्थानांतरित करने में कुछ भी मुश्किल नहीं है:

 - src/  - components/    - product/      - product.jsx      - ...      - product-price/        - product-price.jsx 

परीक्षण फाइलें उसी स्थान पर स्थित होती हैं, जहां परीक्षण के तहत घटकों की फाइलें होती हैं।

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

• घटक फ़ाइल नाम: auth.js
• टेस्ट फ़ाइल नाम: auth.test.js

इस दृष्टिकोण में कई ताकतें हैं:

• यह परीक्षण फ़ाइलों को खोजने के लिए आसान बनाता है। एक नज़र में, आप समझ सकते हैं कि क्या उस घटक के लिए एक परीक्षण है जिसके साथ मैं काम कर रहा हूं।
• सभी आवश्यक आयात कमांड बहुत सरल हैं। परीक्षण में, परीक्षण किए गए कोड को आयात करने के लिए, आपको __tests__ फ़ोल्डर से बाहर निकलने, कहने वाले संरचनाओं को बनाने की आवश्यकता नहीं है। ऐसी टीमें बेहद साधारण दिखती हैं। उदाहरण के लिए, इस तरह: import Auth from './auth' । import Auth from './auth' ।

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

सीएसएस मॉड्यूल

मैं CSS मॉड्यूल का बहुत बड़ा प्रशंसक हूं। हमने पाया कि वे घटकों के लिए मॉड्यूलर सीएसएस नियम बनाने के लिए महान हैं।

इसके अलावा, मैं वास्तव में स्टाइल-कंपोनेंट्स टेक्नोलॉजी पसंद करता हूं। हालांकि, परियोजनाओं पर काम के दौरान जिसमें कई डेवलपर्स ने भाग लिया, यह पता चला कि परियोजना में वास्तविक सीएसएस फ़ाइलों की उपस्थिति प्रयोज्य बढ़ जाती है।

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

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

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

लगभग हमेशा, एक फ़ाइल में केवल एक घटक कोड रखा जाता है

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

उदाहरण के लिए, यदि मैं एक <Product> घटक बनाता हूं, और मुझे कीमत प्रदर्शित करने के लिए कोड का एक छोटा टुकड़ा चाहिए, तो मैं यह कर सकता हूं:

 const Price = ({ price, currency }) => (  <span>    {currency}    {formatPrice(price)}  </span> ) const Product = props => {  // ,      !  return (    <div>      <Price price={props.price} currency={props.currency} />      <div>loads more stuff...</div>    </div>  ) } 

इस दृष्टिकोण के बारे में अच्छी बात यह है कि मुझे <Price> घटक के लिए एक अलग फ़ाइल बनाने की आवश्यकता नहीं थी, और यह घटक विशेष रूप से <Product> घटक के लिए उपलब्ध है। हम इस घटक को निर्यात नहीं करते हैं, इसलिए इसे आवेदन में कहीं और आयात नहीं किया जा सकता है। इसका मतलब यह है कि जब पूछा जाए कि क्या <Price> को एक अलग फ़ाइल में रखा जाए, तो आप एक स्पष्ट, सकारात्मक जवाब दे सकते हैं यदि आपको इसे कहीं और आयात करने की आवश्यकता है। अन्यथा, आप <Price> कोड को एक अलग फ़ाइल में डाले बिना कर सकते हैं।

सार्वभौमिक घटकों के लिए अलग फ़ोल्डर

हम हाल ही में सार्वभौमिक घटकों का उपयोग कर रहे हैं। वे, वास्तव में, हमारी डिजाइन प्रणाली बनाते हैं (जिसे हम किसी दिन प्रकाशित करने की योजना बनाते हैं), लेकिन अभी तक हमने छोटे - जैसे <Button> और <Logo> जैसे घटकों के साथ शुरुआत की है। एक घटक को "सार्वभौमिक" माना जाता है यदि यह साइट के एक विशिष्ट भाग से बंधा नहीं है, लेकिन उपयोगकर्ता इंटरफ़ेस के निर्माण खंडों में से एक है।

इसी तरह के घटक आपके स्वयं के फ़ोल्डर ( src/components/generic ) में स्थित हैं। यह सभी सार्वभौमिक घटकों के साथ काम को बहुत सरल करता है। वे एक ही स्थान पर हैं - यह बहुत सुविधाजनक है। समय के साथ, जैसे-जैसे परियोजना बढ़ती है, हम सार्वभौमिक घटकों के साथ काम को और सरल बनाने के लिए एक स्टाइल गाइड (हम प्रतिक्रिया-स्टाइलग्यूडीस्ट के बड़े प्रशंसक हैं) विकसित करने की योजना बनाते हैं।

आयात प्रविष्टियों के लिए उपनाम का उपयोग करना

हमारी परियोजनाओं में अपेक्षाकृत सपाट फ़ोल्डर संरचना यह सुनिश्चित करती है कि आयात कमांड में बहुत लंबी संरचनाएं नहीं हैं जैसे ../../ । लेकिन उनके बिना करना कठिन है। इसलिए, हम आयात कमांड को सरल बनाने वाले उपनामों को कॉन्फ़िगर करने के लिए बैबल-प्लगइन-मॉड्यूल-रिज़ॉल्वर का उपयोग किया।

आप वेबपैक के साथ भी ऐसा कर सकते हैं, लेकिन बैबल प्लगइन के लिए धन्यवाद, वही आयात कमांड परीक्षण में काम कर सकता है।

हमने इसे एक जोड़ी उपनाम के साथ कॉन्फ़िगर किया है:

 {  components: './src/components',  '^generic/([\\w_]+)': './src/components/generic/\\1/\\1', } 

पहला बेहद सरल है। यह आपको किसी भी घटक को आयात करने की अनुमति देता है, शब्द components साथ कमांड शुरू करता है। सामान्य दृष्टिकोण में, आयात आदेश कुछ इस तरह दिखते हैं:

 import Product from '../../components/product/product' 

इसके बजाय, हम उन्हें इस तरह लिख सकते हैं:

 import Product from 'components/product/product' 

दोनों कमांड एक ही फाइल को इम्पोर्ट करते हैं। यह बहुत सुविधाजनक है, क्योंकि यह आपको फ़ोल्डर संरचना के बारे में नहीं सोचने देता है।

दूसरा उपनाम थोड़ा और जटिल है:

 '^generic/([\\w_]+)': './src/components/generic/\\1/\\1', 

हम यहां रेगेक्स का उपयोग करते हैं। यह आयात आदेशों को खोजता है जो generic साथ शुरू होते हैं (अभिव्यक्ति की शुरुआत में ^ साइन आपको केवल उन कमांड्स को चुनने की अनुमति देता है जो generic शुरू होते हैं) और generic/ बाद generic/ समूह में क्या है इसे कैप्चर करता है। उसके बाद, हम पर कब्जा किए गए टुकड़े ( \\1 ) का उपयोग करते हैं ./src/components/generic/\\1/\\1 निर्माण करते हैं।

परिणामस्वरूप, हम इस तरह के सार्वभौमिक घटकों के लिए आयात कमांड का उपयोग कर सकते हैं:

 import Button from 'generic/button' 

वे निम्न आदेशों में परिवर्तित हो जाते हैं:

 import Button from 'src/components/generic/button/button' 

उदाहरण के लिए, यह कमांड एक सार्वभौमिक बटन का वर्णन करते हुए JSX फ़ाइल आयात करने का कार्य करता है। हमने यह सब किया क्योंकि यह दृष्टिकोण सार्वभौमिक घटकों के आयात को बहुत सरल करता है। इसके अलावा, यह अच्छी तरह से हमारी सेवा करेगा यदि हम परियोजना फाइलों की संरचना को बदलने का फैसला करते हैं (यह, जैसा कि हमारी डिजाइन प्रणाली बढ़ रही है, बहुत संभव है)।

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

उपयोगिताओं के लिए यूनिवर्सल लिब फ़ोल्डर

मैं हर समय पुनः प्राप्त करना चाहूंगा कि मैंने कोड के लिए सही जगह खोजने की कोशिश की जो घटक कोड नहीं है। मैंने यह सब विभिन्न सिद्धांतों के अनुसार साझा किया, उपयोगिताओं, सेवाओं, सहायक कार्यों के कोड पर प्रकाश डाला। इन सभी में इतने नाम हैं कि मैंने उन सभी का उल्लेख नहीं किया। अब मैं एक निश्चित फ़ाइल के लिए सही जगह खोजने के लिए "उपयोगिता" और "सहायक फ़ंक्शन" के बीच अंतर जानने की कोशिश नहीं कर रहा हूं। अब मैं एक बहुत सरल और अधिक समझने योग्य दृष्टिकोण का उपयोग करता हूं: यह सब एक एकल lib फ़ोल्डर में आता है।

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

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

इसके अलावा, हमारे पास एक उपनाम है जो कि आवश्यक फ़ोल्डर से आयात को सरल करता है, जिससे आप इस तरह के कमांड का उपयोग कर सकते हैं:

 import formatPrice from 'lib/format_price' 

फ्लैट फ़ोल्डर संरचनाओं से चिंतित न हों, जिससे एक फ़ोल्डर में कई फाइलें संग्रहीत हो सकती हैं। आमतौर पर ऐसी संरचना एक निश्चित परियोजना के लिए आवश्यक होती है।

देशी एपीआई के पीछे तीसरे पक्ष के पुस्तकालयों को छिपाना

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

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

इस समस्या का सबसे अच्छा समाधान अपने स्वयं के एपीआई को विकसित करना है जो अन्य लोगों के उपकरण छुपाता है। यह कुछ ऐसा है जैसे कि एक lib/error-reporting.js reportError() मॉड्यूल जो lib/error-reporting.js निर्यात करता है। इस मॉड्यूल का मूल संतरी का उपयोग करता है। लेकिन संतरी सीधे इस मॉड्यूल में ही आयात किया जाता है और कहीं नहीं। इसका मतलब यह है कि संतरी को दूसरे टूल से रिप्लेस करना बहुत सरल लगेगा। ऐसा करने के लिए, एक स्थान पर एक फ़ाइल को बदलने के लिए पर्याप्त होगा। जब तक इस फ़ाइल का सार्वजनिक API अपरिवर्तित रहता है, तब तक परियोजना के बाकी लोगों को पता भी नहीं चलेगा कि जब reportError() कॉल कर रही है, तो यह संतरी नहीं है जिसका उपयोग किया जाता है, लेकिन कुछ और।

कृपया ध्यान दें कि मॉड्यूल के सार्वजनिक एपीआई को उन कार्यों को कहा जाता है जो इसे निर्यात करते हैं और उनके तर्क। उन्हें मॉड्यूल का सार्वजनिक इंटरफ़ेस भी कहा जाता है।

PropTypes (या टाइपस्क्रिप्ट या फ़्लो जैसे टूल) का उपयोग करना

जब मैं प्रोग्रामिंग करता हूं, तो मैं खुद के तीन संस्करणों के बारे में सोचता हूं:

• अतीत से जैक और उसने लिखा कोड (कभी-कभी संदिग्ध कोड)।
• आज का जैक, और वह कोड जो वह अब लिखता है।
• भविष्य से जैक। जब मैं खुद इस भविष्य के बारे में सोचता हूं, तो मैं खुद से वर्तमान के बारे में पूछता हूं कि मैं कैसे कोड लिख सकता हूं जो भविष्य में मेरे जीवन को आसान बना देगा।

यह अजीब लग सकता है, लेकिन मुझे यह उपयोगी लगा, यह सोचते हुए कि कोड कैसे लिखना है, निम्नलिखित प्रश्न पूछें: "छह महीने में यह कैसे होगा?"।

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

यदि आप आगे भी जाते हैं, तो गुणों को यथासंभव सटीक रूप से वर्णित करने की सिफारिश की जाती है। उदाहरण के लिए, आप यह कर सकते हैं:

 blogPost: PropTypes.object.isRequired 

लेकिन ऐसा करना बेहतर होगा:

 blogPost: PropTypes.shape({  id: PropTypes.number.isRequired,  title: PropTypes.string.isRequired,  //    }).isRequired 

पहले उदाहरण में, न्यूनतम आवश्यक जांच की जाती है। दूसरे में, डेवलपर को बहुत अधिक उपयोगी जानकारी दी जाती है। वे बहुत काम में आएंगे, उदाहरण के लिए, यदि कोई व्यक्ति ऑब्जेक्ट में उपयोग किए गए एक निश्चित क्षेत्र के बारे में भूल जाता है।

तीसरे पक्ष के पुस्तकालयों का उपयोग केवल तब किया जाता है जब उन्हें वास्तव में जरूरत होती है।

यह टिप रिएक्ट हुक के आगमन के साथ पहले से कहीं अधिक प्रासंगिक है। उदाहरण के लिए, मैं थ्रेड साइट के कुछ हिस्सों में से एक के बड़े परिवर्तन में लगा हुआ था और तीसरे पक्ष के पुस्तकालयों के उपयोग पर विशेष ध्यान देने का निर्णय लिया। , , . ( ), . , React-. — , , React API Context, .

, , Redux, . , ( , ). , , , .

— , , . .

 //     emitter.send('user_add_to_cart') //     emitter.on('user_add_to_cart', () => {  //  -  }) 

, . , . , « ». , , , . . «» - , . , , .

Redux. . , . , , user_add_to_cart , . . , , Redux, . , Redux , .

, , , , :

• , , . .
• , , . , .
• , - , . , , .

- , . , , . , , , «» .

, , API Context - .

, (, , ). : , .

, , , . :

 const wrapper = mount(  <UserAuth.Provider value=>    <ComponentUnderTest />  </UserAuth.Provider> ) 

:

 const wrapper = mountWithAuth(ComponentUnderTest, {  name: 'Jack',  userId: 1, }) 

:

• . — , , , .
• — mountWithAuth . , .

, test-utils.js . , — . .

परिणाम

. , , , , . , , . , : . . - , .

प्रिय पाठकों! React-?