निर्देश लिखने के लिए कब?

Question

कोणीय हमें निर्देश लिखने के लिए एक तंत्र प्रदान करता है - जो यह कर सकता है में बेहद शक्तिशाली है। लेकिन जो चीज मैं सोचता रहता हूं वह है - आप वास्तव में किस परिदृश्य में अपने आप के एक कस्टम निर्देश लिखना चाहिए।

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

https://stackoverflow.com/questions/16101073/angularjs-directive-is-not-working-in-ie-10

Fire button click in AngularJS

angularjs: using a directive inside the ui-bootstrap modal

कुछ उदाहरण परिदृश्यों। मैं वैसे भी उन पर नहीं उठा रहा हूं..क्योंकि मुझे यकीन है कि यह किसी के लिए स्पष्ट नहीं है जब हमें निर्देश का उपयोग/लिखना चाहिए।

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

संपादित करें:

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

सरल निर्देशों के बारे में अच्छी बात (निर्देश जो केवल 1 चीज करते हैं!) यह है कि वे परीक्षण करना बिल्कुल आसान हैं। यदि आप सभी एनजी निर्देशों को देखते हैं तो वे सभी 1 चीज करते हैं और वह चीज़ बहुत अच्छी तरह से करते हैं।

कोणीय में पुन: प्रयोज्य "विचार" (घटक नहीं!) को परिभाषित करने का सबसे अच्छा तरीका क्या है? क्या इसे निर्देश में लिखा जाना चाहिए? या कोई बेहतर तरीका है?

यह आश्चर्यजनक होगा अगर इस मामले में कोणीय देव की एक राय है!

Answer 1

अच्छा ... काफी अच्छा सवाल है।

मेरा मानना ​​है कि निर्देश मुख्य रूप से "extending HTML so you can build a DSL" के लिए हैं, उत्पादकता और कोड गुणवत्ता में सुधार।

सवाल यह है कि यह चीजों को घटाने के माध्यम से हासिल किया जाता है। लेकिन यह का सबसे महत्वपूर्ण है कि हम समझते हैं कि निर्देश केवल दृश्य घटकों के बारे में नहीं है, न केवल templating, बल्कि व्यवहार के बारे में भी है।

, संक्षेप करने के निर्देशों का उपयोग करके आप कर सकते हैं:

1. करने के लिए एक डीएसएल तत्वों व्यवहार
2. बनाने बढ़ाने बनाने डीएसएल विगेट्स, तो आप पहले से ही अपने आप को दोहरा
3. रैपिंग विद्यमान घटकों बंद कर सकते हैं, आपको उत्पादकता खरीदना।
4. अनुकूलन

बढ़ाना व्यवहार व्यवहार componentizing से ज्यादा कुछ नहीं है। ng-click, उदाहरण के लिए, किसी भी तत्व पर क्लिक करने योग्य व्यवहार जोड़ता है। कल्पना कीजिए कि आप दर्जनों खींचने योग्य तत्वों के साथ एक ऐप बना रहे हैं। तत्व तत्व को बढ़ाने के लिए निर्देश तैयार करेंगे, जिससे तत्व दृश्य (<span draggable>Test</span>) को छूए बिना ड्रैगगेबल बना दिया जा सकेगा। फिर भी एक और उदाहरण, कल्पना करें कि आपको माउस होवर पर विशेष संकेत मिलेगा। title विशेषता इसके लिए उपयुक्त नहीं है, तो आप अपना खुद का my-title विशेषता बना सकते हैं, जो स्वचालित रूप से माउस होवर (<span my-title="Some caption">Test</span>) पर अपना "विशेष संकेत" बनाते हैं।

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

यह अंतिम व्यक्ति हमें एक और चेहरा देता है: templating। न केवल आलसी लोगों के लिए, बल्कि DRY principle के बाद कोड गुणवत्ता और रखरखाव में सुधार करने के लिए। यदि आप कंट्रोलर कोड, एचटीएमएल स्ट्रक्चर, या कुछ और दोहरा रहे हैं, तो क्यों नहीं, इसे टेम्पलेट और कंप्यूटरीकरण क्यों करें, है ना? इस नौकरी के लिए निर्देश आपका लड़का है।

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

रैपिंग प्लगइन्स, हर jQuery प्लगइन के लिए के बारे में

(लेकिन हो सकता है MooTools, Ext ...), आप एक नियंत्रक बनाने के लिए, है वाला उस पर $('element').plugin() कहते हैं, और देखभाल कि jQuery घटनाओं बदल सकते हैं और $ अपने दायरे को पचाने तुम्हारे लिए। यह निर्देश का एक और सही उपयोग है। आप एक निर्देश बना सकते हैं जो आपके तत्व पर .plugin() लागू करता है, घटनाओं को सुनता है और आपके लिए अपने दायरे को बदलता/पचता है। यह Angular UI Project सब कुछ है, एक नज़र डालें।

एक अंतिम बिंदु अनुकूलन है। मैंने हाल ही में बनाया और ऐप जो गतिशील कॉलम और पंक्तियों (एक ग्रिड) के साथ तालिकाओं को बनाता है। सवाल यह है कि वास्तविक समय में डेटा अपडेट किया गया है! और हेडर बनाने के लिए एनजी-दोहराव के अंदर एनजी-दोहराना, एप्लिकेशन प्रदर्शन को मार रहा था (प्रत्येक $apply चक्र में नेस्टेड लूप, प्रत्येक आधे सेकेंड में होता है)। तो आप एक निर्देश बना सकते हैं जो कॉलम टेम्पलेट बनाते हैं और अभी भी ng-repeat का उपयोग करते हैं, लेकिन आपके पास केवल कॉलम संस्करण पर कॉलम के माध्यम से लूप होगा।

तो, ऊपर लपेटकर, मेरा मानना ​​है कि निर्देशों व्यवहार componentizing और फार्म (templating), जो आप producitivity और कोड गुणवत्ता खरीदने के बारे में हैं।

Answer 2

मैं व्यक्तिगत रूप से निर्देश लिखता हूं, क्योंकि वे मेरे कार्यक्रम को और अधिक घोषणात्मक बनाते हैं।

एक उदाहरण: एक JSON में -, HTML प्रपत्र पार्सर मैं हाल ही में किए गए> मैं एक "फ़ॉर्म तत्व" निर्देश, कि JSON तत्व एक आवश्यक निर्देशों बनाने के रूप में यह बच्चों है पार्स बनाया। इस तरह मेरे पास विशिष्ट व्यवहार और विधियों के साथ प्रत्येक फ़ील्ड प्रकार के लिए निर्देश है। साथ ही, सभी तत्वों के बीच साझा किया गया कोई भी सामान्य व्यवहार फॉर्म-एलिमेंट निर्देश में है।

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

EDIT - टिप्पणियों के माध्यम से अनुरोध के रूप में कोड का एक स्निपेट शामिल था।

/** 
    * Form Element 
    * ============ 
    * 
    * Handles different elements: 
    * Assigns diferent directives according to the element type 
    * Instanstiates and maintains the active property on the formElem 
    */ 
    .directive("formElement", ['$compile', function($compile){ 
    return{ 
     restrict: "E", 
     scope:{formElemModel: '='}, 
     link: function(scope, element, attrs){ 
      var template = ''; 
      var type = scope.formElem.type; 
      switch (type){ 
       case "field": 
        template = 
         "<form-field-"+scope.formElemModel.fieldType+" ng-switch-when='true'>\ 
         </form-field-"+scope.formElemModel.fieldType+">"; 
        break; 
       default: 
        template = "<form-"+type+" ng-switch-when='true' ></form-"+type+">"; 
        break; 
      } 
      element.html(template); 
      $compile(element.contents())(scope); 

     // Active state of form Element 
     scope.formElem.active = true; 
     scope.testActive = function(){ 
      if(scope.$parent.formElem && scope.$parent.formElem.active == false){ 
      scope.formElem.active = false; 
      } 
      else{ 
      scope.formElem.active = 
       scope.meetsRequirements(scope.formElem.requirements); 
      } 
     } 
     scope.$watch("meetsRequirements(formElem.requirements)", scope.testActive); 
     scope.$watch("$parent.formElem.active", scope.testActive); 
     } 
    } 
    }])