अन्य भाषाओं से पैटर्न और आपके फ़्रंटएंड प्रोजेक्ट्स को बेहतर बनाने के लिए फ़्रेमवर्क

मैं बारह साल से प्रोग्रामिंग कर रहा हूं और कई भाषाओं के साथ काम कर चुका हूं। इनमें C , C++ , Java , Python , C# और अंत में JavaScript शामिल हैं। हर भाषा या ढांचे के अपने नियम होते हैं। उदाहरण के लिए, रस्ट फ़ंक्शन नामों के लिए स्नेक-केस का उपयोग करता है।

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

कार्यात्मक प्रोग्रामिंग

मेरी पहली युक्ति सी से आती है, जो पहली भाषा मैंने सीखी। याद रखें जब हम रिएक्ट विद क्लासेस लिखते थे? इसके बारे में सोचकर ही मुझे ठंड लग जाती है। जब रिएक्ट ने कार्यात्मक घटकों पर स्विच किया, तो इसने कोड को न केवल पढ़ने में आसान बना दिया, बल्कि परीक्षण करना भी आसान बना दिया।

यह कार्यात्मक प्रोग्रामिंग के सिद्धांतों के साथ भी बेहतर तालमेल बिठाता है।

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

कार्यात्मक प्रोग्रामिंग सिद्धांतों का पालन करना मेरे हर फ्रंटएंड एप्लिकेशन में होना चाहिए।

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

कोड फ़ॉर्मेटर्स

जब मैंने पहली बार प्रोग्रामिंग शुरू की, तो मैंने कोड स्वरूपण पर ज्यादा ध्यान नहीं दिया। मुझे लगता है कि यह सब विश्वविद्यालय में शुरू हुआ जहां मैं एक सफेद विषय के साथ अपने कूल कोडब्लॉक आईडीई पर सी ++ सीख रहा था।

2016 से GitHub पर अपने पुराने कोड को देखते हुए, मैं देख सकता हूं कि मैंने फ़ॉर्मेटिंग के लिए केवल रिक्त स्थान का उपयोग किया है। मैंने इसका स्वचालित रूप से ध्यान रखने के लिए किसी भी उपकरण का उपयोग नहीं किया।

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

मेरा विश्वास करो, आपको इसका पछतावा नहीं होगा!

ओह, और अपने IDE में फाइल सेव एक्शन पर एक ऑटोफॉर्मेटिंग सेट करना न भूलें!

पूर्व-प्रतिबद्ध क्रियाएँ

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

फाइलनामों के लिए कबाब-केस

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

इसलिए मैंने अपने सभी दृश्यपटल परियोजनाओं के लिए कबाब-केस का उपयोग करने का निर्णय लिया। यह कुछ लाभ प्रदान करता है, जैसे:

• सादगी : मुझे इस बारे में चिंता करने की ज़रूरत नहीं है कि पास्कल-केस, ऊंट-केस, या सांप-केस (यदि आप चाहें) का उपयोग करें। कबाब-केस के साथ, बस एक ही विकल्प है।

• संगति : यदि आप एक टीम पर काम कर रहे हैं, तो कबाब-केस जैसी एकल नामकरण प्रथा को अपनाने से यह सुनिश्चित करने में मदद मिल सकती है कि सभी एक ही पृष्ठ पर हैं और परियोजना व्यवस्थित रहती है। यह न भूलें कि आप यूनिकॉर्न पैकेज का उपयोग करके एस्लिंट नियम के माध्यम से कबाब-केस का उपयोग करने के लिए बाध्य कर सकते हैं:

 'unicorn/filename-case': [ 'error', { case: 'kebabCase', }, ],

• क्रॉस-प्लेटफ़ॉर्म संगतता : विभिन्न ऑपरेटिंग सिस्टम फ़ाइल नामों को अलग-अलग तरीके से संभालते हैं। उदाहरण के लिए, विंडोज़ पूंजीकरण के बारे में परवाह नहीं करता है, लेकिन लिनक्स करता है। कबाब-केस का उपयोग करके, जो लोअरकेस अक्षरों और हाइफ़न का उपयोग करता है, मैं किसी भी मुद्दे से बचता हूँ।

• कोई गिट समस्या नहीं : गिट में लोअरकेस से अपरकेस में फ़ाइल का नाम बदलने में समस्या है। कबाब-केस का उपयोग करने से मुझे इसकी चिंता करने की आवश्यकता नहीं है।

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

फ़ाइल प्रकारों के लिए टैग का उपयोग करना

एक और चीज जो मैंने एंगुलर से उधार ली है कि वे फाइलों का नाम कैसे देते हैं। कोणीय एक तरह से फाइलों के नामकरण की सिफारिश करता है जो उनके कार्य और प्रकार को दर्शाता है। मुझे लगता है कि इससे मेरे लिए नेविगेट करना और प्रोजेक्ट की संरचना को समझना आसान हो जाता है। कोणीय में, फ़ाइल नाम में आमतौर पर तीन भाग होते हैं: सुविधा क्षेत्र, फ़ाइल की भूमिका और फ़ाइल का प्रकार।

उदाहरण के लिए, heroes.component.ts दिखाता है कि फ़ाइल heroes फीचर के लिए एक घटक है और यह एक टाइपस्क्रिप्ट फ़ाइल है। heroes.service.ts heroes के लिए एक सेवा है।

मैं services का बहुत बड़ा प्रशंसक नहीं हूं, लेकिन मैं अपने रिएक्ट घटकों के लिए समान संरचना का उपयोग करता हूं। यहाँ एक उदाहरण है:

 my-component ├── my-component.component.tsx ├── my-component.type.ts ├── my-component.style.css ├── my-component.spec.tsx └── my-component.story.mdx

मैं इस पैटर्न का उपयोग अपने हुक और कार्यों के लिए भी करता हूं। यह पैटर्न मुझे उनसे संबंधित फाइलों के बगल में अपना परीक्षण करना भी सिखाता है।

स्वचालित कोड जनरेशन

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

स्वचालन के साथ, मुझे किसी घटक की मूल संरचना के बारे में सोचने में अधिक समय नहीं देना पड़ता है। यह कार्य स्वचालित हो सकता है, जो मुझे उस पर ध्यान केंद्रित करने की अनुमति देता है जो मैं वास्तव में करना चाहता हूं।

एक 'डोमेन' का उपयोग करना

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

यह वह जगह है जहां हम अपने सभी मुख्य प्रकार और संचालन डालते हैं। यह हमारे ऐप में 'सत्य के स्रोत' के रूप में कार्य करता है।

यदि आप देखना चाहते हैं कि मैं अपने ऐप्स में 'डोमेन' को कैसे प्रबंधित करता हूं, तो आप इस लेख को देख सकते हैं। मैं इस विषय का वर्णन करने में बहुत समय बिताता हूँ।

अपनी वास्तुकला का परीक्षण

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

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

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

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