Khi nào cần viết một chỉ thị?

Question

Góc cung cấp cho chúng ta một cơ chế để viết các chỉ thị - đó là cực kỳ mạnh mẽ trong những gì nó có thể làm. Nhưng điều tôi cứ tự hỏi là - trong kịch bản nào bạn nên thực sự viết một chỉ thị tùy chỉnh của riêng bạn.

Chúng tôi tiếp tục nhìn thấy các câu hỏi trong và xung quanh Stack Overflow với nhiều người cố gắng viết các chỉ thị mà (theo ý kiến ​​của tôi) không cần phải được viết ở nơi đầu tiên. Trong hầu hết các trường hợp, chúng có thể được giải quyết với sự kết hợp lặp lại, chuyển đổi và hiển thị. Xem ví dụ về các câu hỏi có chứa các chỉ thị mà tôi cho rằng không nên là chỉ thị ngay từ đầu!

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

Một số kịch bản ví dụ. Dù sao thì tôi cũng không chọn chúng ... bởi vì tôi chắc chắn là không rõ với bất cứ ai khi chúng ta nên sử dụng/viết một chỉ thị.

Chúng tôi thấy kịch bản nơi mọi người sử dụng chỉ thị làm cơ chế cho việc tạo khuôn mẫu. Đây có phải là cách làm đúng đắn không? đây có phải là cách tốt hơn không? (ng-bao gồm có lẽ?) Có bất kỳ upides/downsides để sử dụng chỉ thị như là một cơ chế templating? Lý do cho câu hỏi này là đôi khi tôi tự hỏi nếu mọi người viết chỉ thị bởi vì đến từ thế giới jquery điều đầu tiên họ có thể nghĩ đến là viết mã thao tác DOM và vì cách góc là không thao tác DOM trong bộ điều khiển mà nó hấp dẫn tất cả mã đó trong chỉ thị.

EDIT:

Tôi tin rằng sự nhầm lẫn này (của xô đẩy mọi thứ bên trong một chỉ thị) phát sinh do góc không có một khái niệm riêng biệt của một "cái nhìn" - không giống như Backbone (mà chỉ có một "tầm nhìn", nhưng không có thành phần nào!). Các chỉ thị là tuyệt vời khi xác định các thành phần - Nhưng tôi nghĩ nếu bạn sử dụng chúng để tạo ra "các khung nhìn", bạn sẽ mất một số cách "góc cạnh". Đây là ý kiến ​​của tôi mặc dù - đó là lý do tại sao tôi đang kêu gọi những gì phần còn lại của cộng đồng góc cạnh nghĩ.

Điều tốt về chỉ thị đơn giản hơn (chỉ thị chỉ thực hiện 1 điều!) Là chúng hoàn toàn dễ kiểm tra. Nếu bạn nhìn vào tất cả các chỉ thị ng tất cả họ làm 1 điều và làm điều đó khá tốt.

Cách tốt nhất để xác định "chế độ xem" có thể tái sử dụng (không phải thành phần!) Trong Angular là gì? Điều đó có nên được viết trong một chỉ thị? đây có phải là cách tốt hơn không?

Sẽ thật tuyệt vời nếu một trong những người phát triển góc có ý kiến ​​về vấn đề này!

Answer 1

Vâng ... câu hỏi khá hay.

Tôi tin rằng chỉ thị chủ yếu có nghĩa là "extending HTML so you can build a DSL", cải thiện năng suất và chất lượng mã.

Câu hỏi đặt ra là điều này đạt được thông qua việc cấu thành mọi thứ. Nhưng nó là của tầm quan trọng nhất mà chúng tôi hiểu rằng chỉ thị không chỉ về các thành phần hình ảnh mà không chỉ là khuôn mẫu, mà còn, về hành vi.

Để tóm tắt, sử dụng chỉ thị bạn có thể:

1. tạo ra một DSL để tăng thêm các yếu tố hành vi
2. tạo widget DSL, vì vậy bạn có thể ngăn chặn lặp lại chính mình
3. gói đã thành phần tồn tại, mua cho bạn năng suất.
4. tối ưu hóa

hành vi Tăng cường biện là gì khác hơn là componentizing hành vi. Ví dụ: ng-click, thêm hành vi có thể nhấp vào bất kỳ phần tử nào. Hãy tưởng tượng bạn đang tạo một ứng dụng với hàng tá yếu tố có thể kéo. Hơn bạn sẽ tạo ra một chỉ thị để tăng thêm hành vi của phần tử, làm cho nó có thể kéo được mà không cần chạm vào phần tử trực quan (<span draggable>Test</span>). Tuy nhiên, một ví dụ khác, hãy tưởng tượng bạn sẽ có những gợi ý đặc biệt về di chuột. title thuộc tính không phù hợp với điều này, sau đó bạn có thể tạo thuộc tính my-title của riêng bạn, tự động tạo "gợi ý đặc biệt" của bạn trên di chuột (<span my-title="Some caption">Test</span>).

Và khi phát triển một ứng dụng, bạn có rất nhiều khái niệm và hành vi cụ thể về miền. Stackoverflow, ví dụ, có một khái niệm mạnh về bỏ phiếu. Bạn có thể bỏ phiếu lên/xuống câu hỏi, câu trả lời, bình luận ... Vì vậy, bạn có thể tạo chỉ thị votable có thể sử dụng lại, điều đó sẽ thêm "hành vi bỏ phiếu" và "tiện ích bỏ phiếu" (mũi tên lên/xuống) để praticaly bất kỳ yếu tố nào.

Điều cuối cùng này cho chúng ta một khuôn mặt khác: khuôn mẫu. Không chỉ cho những người lười biếng, mà còn cải thiện chất lượng mã và khả năng bảo trì sau DRY principle. Nếu bạn đang lặp lại mã bộ điều khiển, cấu trúc HTML hoặc bất kỳ thứ gì khác, tại sao không tạo khuôn mẫu và cấu thành nó, phải không? Chỉ thị là anh chàng của bạn cho công việc này.

Tất nhiên, bạn cũng có một số ứng dụng chung về chỉ thị. Nhiều ứng dụng (không phải để nói tất cả chúng) dựa vào các phần tử có thể nhấp, đây là lý do tại sao chúng tôi có một ví dụ ng-click. Nhiều ứng dụng có khu vực tải lên. Và bạn sẽ làm gì theo cách suy nghĩ của jQuery? Bạn sẽ tạo một plugin jQuery. Đúng? Trong Angular, bạn sẽ tạo ra một Angular Widget (sử dụng các chỉ thị). Bạn thậm chí có thể bọc một plugin đã tồn tại bằng cách sử dụng một chỉ thị, và, một lần nữa, tăng cường hành vi của nó để nó có thể nói chuyện trơn tru với ứng dụng của bạn.

Về gói plugin, để mỗi jQuery plugin (nhưng có thể là MooTools, Ext ...), bạn sẽ phải tạo một bộ điều khiển, gọi $('element').plugin() vào nó, và chăm sóc mà jQuery sự kiện thay đổi và $ tiêu hóa phạm vi của bạn cho bạn. Đây là cách sử dụng hoàn hảo khác của chỉ thị. Bạn có thể tạo một chỉ thị áp dụng .plugin() trên yếu tố của bạn, lắng nghe các sự kiện và thay đổi/tiêu hóa phạm vi của bạn cho bạn. Đây là những gì Angular UI Project là tất cả về, hãy xem.

Điểm cuối cùng là tối ưu hóa. Gần đây tôi đã tạo và ứng dụng tạo bảng với các cột và hàng động (lưới). Câu hỏi đặt ra là dữ liệu được cập nhật trong thời gian thực! Và ng-lặp lại bên trong ng-lặp lại, để tạo tiêu đề, đã giết chết hiệu suất ứng dụng (vòng lặp lồng nhau trong mỗi chu kỳ $apply, xảy ra mỗi nửa giây). Vì vậy, bạn có thể tạo một chỉ thị tạo mẫu cột và vẫn sử dụng ng-repeat bên trong nó, nhưng bạn sẽ có một vòng lặp thông qua các cột chỉ khi các phiên bản cột.

Vì vậy, kết thúc, tôi tin rằng chỉ có khoảng componentizing hành vi và hình thức (khuôn mẫu), mà mua bạn producitivity và mã chất lượng.

Answer 2

Cá nhân tôi viết chỉ thị khá nhiều, vì họ có xu hướng làm cho chương trình của tôi khai báo nhiều hơn.

Ví dụ: trong JSON -> Trình phân tích biểu mẫu HTML Gần đây, tôi đã tạo chỉ thị "phần tử biểu mẫu", phân tích cú pháp phần tử JSON tạo chỉ thị cần thiết vì nó là con. Bằng cách đó tôi có một chỉ thị cho từng loại trường, với hành vi và phương pháp cụ thể. Ngoài ra, bất kỳ hành vi phổ biến nào được chia sẻ giữa tất cả các phần tử đều nằm trong chỉ thị phần tử biểu mẫu.

Bằng cách này, phần tử nhóm là một chỉ thị có ng lặp lại trong mẫu của nó và phần tử tiêu đề đơn giản như h1. Nhưng tất cả có thể có cùng một hành vi có điều kiện (một nhóm chỉ có thể xuất hiện nếu một trường trước đó có một tập hợp giá trị nhất định, ví dụ).Và tất cả cực kỳ sạch sẽ - bất cứ lúc nào tôi cần phải thêm/thay đổi, tất cả đều được đặt hoàn hảo, và html là cực kỳ khai báo.

EDIT - bao gồm một đoạn mã, như được yêu cầu qua nhận xét.

/** 
    * 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); 
     } 
    } 
    }])