AngularJS में एक आवेदन लिखने की योजना है? आपकी मदद के लिए पोस्ट

हमारे सबसे अश्लील और घृणित कार्य जो नैतिकता और सिद्धांतों के सभी मानदंडों से परे हैं, आमतौर पर "क्यों नहीं?" शब्दों के साथ शुरू होते हैं।

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

तो अगर आप कोणीय में एक आवेदन लिखने की योजना बनाते हैं, तो क्यों नहीं?

प्रेरणा

• "लोगों के साथ वैसा ही व्यवहार करें जैसा आप चाहते हैं।" अचानक कोई काम आएगा
• अपने बारे में और टिप्पणियों में विकास के बारे में कुछ नया सीखें।
  
• अपने एप्लिकेशन जनरेटर ASS को बढ़ावा दें।
  

एक कोणीय अनुप्रयोग किस से मिलकर बनता है?

बशर्ते कि कोणीय अनुप्रयोग सेवाओं, नियंत्रकों, निर्देशों और टेम्पलेट्स से युक्त नहीं है?
यह सही है, एक कोणीय अनुप्रयोग में केवल मॉड्यूल और मॉड्यूल होते हैं।

ठीक है स्मार्टास, मॉड्यूल किससे बने होते हैं?

लेकिन मॉड्यूल, बदले में, पहले से ही सेवाओं, नियंत्रकों, निर्देशों, सेवाओं, प्रदाताओं और टेम्पलेट्स से मिलकर बना सकते हैं।

सेवाएं

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

... .factory("$user",function($rootScope, $someLocalStorageService){ var user={ id:null, name:null, isAuthorized:false } if($someLocalStorageService.load("user"))angular.extend(user,$someLocalStorageService.load("user")); $rootScope.$watchCollection(function(){ return user; },function(user){ $someLocalStorageService.save("user",user); }); return user; }); 

इस उदाहरण में, सेवा एक मॉडल और एक पृष्ठभूमि प्रक्रिया है जो ऑब्जेक्ट में परिवर्तन की निगरानी करती है और तुरंत इसे स्थानीय भंडारण में संग्रहीत करती है।

अब कुछ शब्द जहां आप इन सेवाओं के साथ काम कर सकते हैं।

नियंत्रकों

नियंत्रकों में। हम नियंत्रक कॉल करने के तरीकों से सार करते हैं और सार की ओर मुड़ते हैं। और उनका सार सेवाओं के काम को जोड़ने के लिए सरल है। और केवल इस में, हालांकि सबसे अधिक बार ऐसा लगता है कि नियंत्रक डेटा के साथ डिस्प्ले (/ लेआउट / DOM / HTML) को जोड़ने के लिए कार्य करता है। और सिद्धांत रूप में, यह मूल रूप से ऐसा था। पहले, आप नियंत्रक का उपयोग टेम्पलेट में उपयोग किए जाने वाले डेटा तक पहुंचने के लिए कर सकते थे।

 ... .controller("SomeCtrl",function(){ this.var=" "; }); ... <p> {{var}}</p> 

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

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

दिशा निर्देशों

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

निर्देशों की अवशेष क्या है? कि आप बहुत आसानी से तर्क और डेटा को ui तत्वों से बाँध सकते हैं। सिद्धांत रूप में, यदि आप खुद को ऐसा लक्ष्य बनाते हैं, तो आप चयनकर्ता के रूप में इस तरह के शब्द के बारे में पूरी तरह से भूल सकते हैं।

एक निर्देश क्या है? DOM तत्व से कुछ जुड़ा हुआ है। कैसे बंधे? टैग के रूप में, टैग विशेषता के रूप में, टैग क्लास के रूप में।

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

मुद्दा बनाएँ

इसकी आवश्यकता क्यों है? ताकि जब आप उत्पादन पर एक पृष्ठ लोड करते हैं, तो आपके पास प्रोजेक्ट फ़ाइलों को डाउनलोड करने के लिए सैकड़ों कनेक्शन नहीं हैं, लेकिन, आदर्श रूप से, एक। विकास के दौरान पेन के साथ जोड़े गए फाइलों को पंजीकृत करने की आवश्यकता नहीं थी।

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

इसलिए, मैं व्यक्तिगत रूप से Essential.js का समर्थक हूं । क्यों? ठीक है, सबसे पहले, निर्भरताएं कोड में लिखी जाती हैं, दूसरी बात, जब ब्राउज़र को विकसित करना स्वयं सभी आवश्यक फ़ाइलों को लोड करेगा और सिलाई की आवश्यकता नहीं है, और तीसरा, जब यह उत्पादन की बात आती है, तो आपकी सभी फाइलें एक में संकुचित हो जाएंगी, और यदि आप चाहें, तो। minifitsirovany।

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

वास्तुकला के बारे में

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

 (boolean)        = (boolean)       || (boolean)   

खैर, यह महत्वहीन नहीं है कि आप अपने आवेदन का परीक्षण कैसे करेंगे। यदि आप नियंत्रकों, सेवाओं, निर्देशों के लिए अलग से परीक्षण चलाना चाहते हैं, तो यह स्पष्ट है कि आपको उन्हें अलग-अलग मॉड्यूल "App.controllers", "App.services", "App.directives", आदि में रखना होगा।

लेकिन वास्तुकला के लिए, यह देखना हमेशा अच्छा होता है कि दूसरे कैसे करते हैं।

NGBP

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

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

कोणीय बीज

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

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

कोणीय-की आवश्यकता होती है-बीज

यदि आप कोणीय-बीज पसंद करते हैं, लेकिन आवश्यकता का उपयोग करना चाहते हैं, तो कृपया उपयोग करें । पेशेवरों और विपक्ष कोणीय-बीज के समान हैं। यह संभव है कि आवश्यकता का उपयोग करके। क्या आपके लिए अपनी परियोजना को संकलित करना आसान होगा, लेकिन ऐसा तब होता है जब आप आवश्यकता-आशावादी का उपयोग करते हैं

कोणीय-सुपर-बीज

क्या गायब है और समुदाय की पेशकश करने के लिए इस विषय पर, आवेदन की वास्तुकला पर चिंतन करते हुए, मैं इस परिणाम पर आया।

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

घटक मॉड्यूल एक अलग फ़ाइल में भी परिभाषित और वर्णित हैं।

इस दृष्टिकोण का स्पष्ट दोष यह है कि प्रत्येक नए नियंत्रक / सेवा / निर्देश को बनाते समय, आपको उन्हें घोषित करने के लिए नियमित संचालन का एक समूह बनाने की आवश्यकता होती है। यही है, आप एक नया निर्देश बनाना चाहते हैं: एक निर्देश फ़ाइल, एक टेम्पलेट फ़ाइल, एक शैली फ़ाइल बनाएँ। घातक नहीं, लेकिन तंग आ सकता है। और यहाँ यह कहने का समय है YO ASS!

फ़र्मर

जब मैं पहली बार योमन वेबसाइट पर गया, तो मैंने सेवा सुविधाओं की सराहना नहीं की। ठीक है, क्या आप कुछ विशेष टेम्पलेट्स के अनुसार अलग-अलग फाइलें बना सकते हैं। खैर, यह वही है जो मैं संपादक में कॉन्फ़िगर कर सकता हूं।

लेकिन जब मैंने इस तथ्य के बारे में सोचा कि न केवल अलग-अलग फाइलें बनाना अच्छा होगा, बल्कि कुछ अन्य ऑपरेशन भी करना होगा, तब यह था कि मैंने एक कॉमरेड फोरमैन को देखा।

इस तरह के एक जनरेटर के परिणामस्वरूप निकला।

हमने योमन को लगा दिया

 npm install -g yo 

हमने जनरेटर लगा दिया

 npm install -g generator-ass 

बुलबुल क्या है? आप इस तरह से अपने कंसोल में क्या कर सकते हैं:

 yo ass 

और आपके फ़ोल्डर में एक नया एप्लिकेशन दिखाई देगा। खैर, फिर और।

 yo ass:page main 

पृष्ठ, स्टाइलशीट, नियंत्रक के लिए स्वचालित रूप से एक नया टेम्पलेट बनाएं और इसे राउटर में प्लग करें

एक मॉड्यूल बनाएँ

 yo ass:module first 

मॉड्यूल तैयार है और पहले से ही टर्नकी दिया गया है ।

और अब इसमें एक निर्देश बनाते हैं

 yo ass:module firstDirective 

हम सवाल का जवाब देते हैं, जिसमें मॉड्यूल और सब कुछ ठीक है।

मुझे तुरंत कहना होगा कि अभी पर्याप्त परीक्षण और moq नहीं है। सब कुछ होगा

मुझे उम्मीद है कि कोई काम आएगा। क्यों नहीं?