Thật là một câu hỏi tuyệt vời! Tôi muốn yêu để nghe những gì người khác nói gì, nhưng đây là những hướng dẫn tôi sử dụng.
Tiền đề cao độ: phạm vi được sử dụng làm "chất keo" mà chúng ta sử dụng để liên lạc giữa bộ điều khiển chính, lệnh và mẫu chỉ thị.
Phạm vi phụ huynh: scope: false vì vậy không có phạm vi mới nào cả
Tôi không sử dụng điều này rất thường xuyên, nhưng như @MarkRajcok đã nói, nếu lệnh không truy cập bất kỳ biến phạm vi nào (và rõ ràng là không đặt bất kỳ biến nào!) Thì điều này cũng ổn đối với tôi. Đây là cũng hữu ích cho chỉ con được chỉ được sử dụng trong bối cảnh các thị mẹ (mặc dù luôn có những trường hợp ngoại lệ này) và không có một bản mẫu. Về cơ bản, mọi thứ với mẫu không thuộc về việc chia sẻ một phạm vi, vì bạn vốn đã phơi bày phạm vi đó để truy cập và thao tác (nhưng tôi chắc chắn có những ngoại lệ đối với quy tắc này).
Lấy ví dụ, gần đây tôi đã tạo ra một lệnh vẽ đồ họa vector (tĩnh) bằng thư viện SVG tôi đang trong quá trình viết. Nó $observelà hai thuộc tính ( widthvà height) và sử dụng các thuộc tính trong tính toán của nó, nhưng nó không đặt và cũng không đọc bất kỳ biến phạm vi nào và không có mẫu. Đây là một trường hợp sử dụng tốt để không tạo ra một phạm vi khác; chúng ta không cần một cái, vậy tại sao phải bận tâm?
Nhưng trong một chỉ thị SVG khác, tuy nhiên, tôi yêu cầu một bộ dữ liệu để sử dụng và ngoài ra phải lưu trữ một chút trạng thái. Trong trường hợp này, sử dụng phạm vi cha mẹ sẽ là vô trách nhiệm (nói chung, nói chung). Vì vậy, thay vào đó ...
Phạm vi trẻ em: scope: true
Các chỉ thị có phạm vi con được nhận biết theo ngữ cảnh và được dự định tương tác với phạm vi hiện tại.
Rõ ràng, một lợi thế chính của điều này so với phạm vi cô lập là người dùng có thể tự do sử dụng phép nội suy trên bất kỳ thuộc tính nào họ muốn; ví dụ: sử dụng class="item-type-{{item.type}}"trên một lệnh có phạm vi cách ly sẽ không hoạt động theo mặc định, nhưng hoạt động tốt trên một lệnh có phạm vi con bởi vì bất cứ thứ gì được nội suy vẫn có thể được tìm thấy theo mặc định trong phạm vi cha. Ngoài ra, bản thân lệnh có thể đánh giá các thuộc tính và biểu thức một cách an toàn trong bối cảnh phạm vi của chính nó mà không phải lo lắng về ô nhiễm hoặc thiệt hại cho cha mẹ.
Ví dụ, một tooltip là một cái gì đó vừa được thêm vào; một phạm vi cô lập sẽ không hoạt động (theo mặc định, xem bên dưới) bởi vì chúng tôi dự kiến sẽ sử dụng các chỉ thị hoặc thuộc tính nội suy khác ở đây. Chú giải công cụ chỉ là một sự nâng cao. Nhưng tooltip cũng cần đặt một số thứ trên phạm vi để sử dụng với một chỉ thị phụ và / hoặc khuôn mẫu và rõ ràng là để quản lý trạng thái của chính nó, vì vậy sẽ thực sự rất tệ khi sử dụng phạm vi cha. Chúng tôi hoặc đang làm ô nhiễm nó hoặc làm hỏng nó, và cũng không phải là bueno.
Tôi thấy mình sử dụng phạm vi con thường xuyên hơn so với phạm vi cách ly hoặc cha mẹ.
Phạm vi cô lập: scope: {}
Đây là cho các thành phần tái sử dụng. :-)
Nhưng nghiêm túc, tôi nghĩ "các thành phần có thể tái sử dụng" là "các thành phần độc lập". Mục đích là chúng sẽ được sử dụng cho một mục đích cụ thể, do đó, việc kết hợp chúng với các chỉ thị khác hoặc thêm các thuộc tính được nội suy khác vào nút DOM vốn không có ý nghĩa.
Để cụ thể hơn, mọi thứ cần thiết cho chức năng độc lập này được cung cấp thông qua các thuộc tính được chỉ định được đánh giá trong ngữ cảnh của phạm vi cha; chúng là các chuỗi một chiều ('@'), biểu thức một chiều ('&') hoặc các ràng buộc biến hai chiều ('=').
Trên các thành phần độc lập, không cần thiết phải áp dụng các chỉ thị hoặc thuộc tính khác trên nó bởi vì nó tồn tại bởi chính nó. Phong cách của nó được điều chỉnh bởi mẫu riêng của nó (nếu cần thiết) và có thể có nội dung phù hợp được bao gồm (nếu cần). Nó là độc lập, vì vậy chúng tôi cũng đặt nó trong một phạm vi tách biệt để nói: "Đừng gây rối với điều này. Tôi sẽ cung cấp cho bạn một API được xác định thông qua một vài thuộc tính này."
Một thực hành tốt nhất là loại trừ càng nhiều thứ dựa trên mẫu khỏi các hàm điều khiển và liên kết chỉ thị càng tốt. Điều này cung cấp một điểm cấu hình "giống như API" khác: người dùng lệnh có thể chỉ cần thay thế mẫu! Tất cả các chức năng đều giữ nguyên và API nội bộ của nó không bao giờ được chạm vào, nhưng chúng ta có thể gây rối với việc thực hiện kiểu dáng và DOM nhiều như chúng ta cần. ui / bootstrap là một ví dụ tuyệt vời về cách làm tốt điều này bởi vì Peter & Pawel thật tuyệt vời.
Phạm vi cô lập cũng là tuyệt vời để sử dụng với loại trừ. Lấy các tab; chúng không chỉ là toàn bộ chức năng, mà bất cứ thứ gì bên trong nó đều có thể được đánh giá tự do từ trong phạm vi cha mẹ trong khi để các tab (và panes) làm bất cứ điều gì chúng muốn. Các tab rõ ràng có trạng thái riêng , thuộc về phạm vi (để tương tác với mẫu), nhưng trạng thái đó không liên quan gì đến bối cảnh mà nó được sử dụng - nó hoàn toàn bên trong những gì tạo ra một lệnh chỉ thị tab. Hơn nữa, sẽ không có ý nghĩa gì khi sử dụng bất kỳ chỉ thị nào khác với các tab. Chúng là các tab - và chúng tôi đã có chức năng đó!
Bao quanh nó với nhiều chức năng hơn hoặc bao gồm nhiều chức năng hơn, nhưng chỉ thị là những gì nó đã có.
Tất cả những gì đã nói, tôi nên lưu ý rằng có nhiều cách xung quanh một số hạn chế (nghĩa là các tính năng) của một phạm vi cô lập, như @ProLoser gợi ý trong câu trả lời của anh ấy. Ví dụ, trong phần phạm vi con, tôi đã đề cập đến phép nội suy trên các thuộc tính không trực tiếp phá vỡ khi sử dụng phạm vi cách ly (theo mặc định). Nhưng người dùng có thể, ví dụ, chỉ cần sử dụng class="item-type-{{$parent.item.type}}"và nó sẽ hoạt động trở lại. Vì vậy, nếu có một lý do thuyết phục để sử dụng phạm vi cô lập trên phạm vi con nhưng bạn lo lắng về một số hạn chế này, hãy biết rằng bạn có thể giải quyết hầu như tất cả chúng nếu bạn cần.
Tóm lược
Các chỉ thị không có phạm vi mới là chỉ đọc; họ hoàn toàn đáng tin cậy (tức là nội bộ cho ứng dụng) và họ không chạm vào jack. Các chỉ thị với phạm vi con thêm chức năng, nhưng chúng không phải là chức năng duy nhất . Cuối cùng, phạm vi cô lập là dành cho các chỉ thị là toàn bộ mục tiêu; chúng là độc lập, vì vậy không sao (và hầu hết "chính xác") để cho chúng đi lừa đảo.
Tôi muốn đưa ra những suy nghĩ ban đầu của mình, nhưng khi tôi nghĩ ra nhiều thứ hơn, tôi sẽ cập nhật điều này. Nhưng tào lao thần thánh - đây là một câu trả lời SO ...
PS: Hoàn toàn tiếp tuyến, nhưng vì chúng ta đang nói về phạm vi, tôi thích nói "nguyên mẫu" trong khi những người khác thích "nguyên mẫu", điều này có vẻ chính xác hơn nhưng chỉ không nói gì cả. :-)