¡Qué gran pregunta! Me encantaría escuchar lo que otros tienen que decir, pero aquí están las pautas que uso.
La premisa de gran altitud: el alcance se usa como el "pegamento" que usamos para comunicarnos entre el controlador principal, la directiva y la plantilla de la directiva.
Alcance principal: scope: false por lo tanto, no hay ningún alcance nuevo
No uso esto muy a menudo, pero como dijo @MarkRajcok, si la directiva no accede a ninguna variable de alcance (¡y obviamente no establece ninguna!), Entonces esto está bien en lo que a mí respecta. Esto también es útil para las directivas secundarias que solo se usan en el contexto de la directiva principal (aunque siempre hay excepciones a esto) y que no tienen una plantilla. Básicamente, cualquier cosa con una plantilla no pertenece compartiendo un alcance, porque expones inherentemente ese alcance para acceso y manipulación (pero estoy seguro de que hay excepciones a esta regla).
Como ejemplo, recientemente creé una directiva que dibuja un gráfico vectorial (estático) usando una biblioteca SVG que estoy en proceso de escribir. Tiene $observedos atributos ( widthy height) y los usa en sus cálculos, pero no establece ni lee ninguna variable de alcance y no tiene plantilla. Este es un buen caso de uso para no crear otro ámbito; no necesitamos uno, entonces ¿por qué molestarse?
Pero en otra directiva SVG, sin embargo, requería un conjunto de datos para usar y además tenía que almacenar un poco de estado. En este caso, usar el ámbito primario sería irresponsable (nuevamente, en términos generales). Así que en vez...
Alcance del niño: scope: true
Las directivas con un ámbito secundario tienen en cuenta el contexto y están destinadas a interactuar con el ámbito actual.
Obviamente, una ventaja clave de esto sobre un alcance aislado es que el usuario es libre de usar la interpolación en cualquier atributo que desee; por ejemplo, el uso class="item-type-{{item.type}}"de una directiva con un ámbito aislado no funcionará de forma predeterminada, pero funciona bien en uno con un ámbito secundario porque lo que sea que se interpola puede encontrarse de forma predeterminada en el ámbito primario. Además, la propia directiva puede evaluar con seguridad los atributos y expresiones en el contexto de su propio alcance sin preocuparse por la contaminación o el daño a los padres.
Por ejemplo, una información sobre herramientas es algo que simplemente se agrega; un alcance aislado no funcionaría (por defecto, ver más abajo) porque se espera que usemos otras directivas o atributos interpolados aquí. La información sobre herramientas es solo una mejora. Pero la información sobre herramientas también necesita establecer algunas cosas en el alcance para usar con una sub-directiva y / o plantilla y obviamente para administrar su propio estado, por lo que sería bastante malo usar el alcance principal. Lo estamos contaminando o dañándolo, y ninguno de los dos es bueno.
Me encuentro usando ámbitos secundarios con más frecuencia que los ámbitos aislados o primarios.
Alcance de aislamiento: scope: {}
Esto es para componentes reutilizables. :-)
Pero en serio, pienso en los "componentes reutilizables" como "componentes autónomos". La intención es que se usen para un propósito específico, por lo que combinarlos con otras directivas o agregar otros atributos interpolados al nodo DOM inherentemente no tiene sentido.
Para ser más específicos, todo lo necesario para esta funcionalidad independiente se proporciona a través de atributos específicos evaluados en el contexto del ámbito principal; son cadenas unidireccionales ('@'), expresiones unidireccionales ('&') o enlaces de variables bidireccionales ('=').
En componentes autocontenidos, no tiene sentido aplicar otras directivas o atributos porque existe por sí mismo. Su estilo se rige por su propia plantilla (si es necesario) y puede tener el contenido apropiado translúcido (si es necesario). Es independiente, por lo que lo ponemos en un ámbito aislado también para decir: "No te metas con esto. Te estoy dando una API definida a través de estos pocos atributos".
Una buena práctica es excluir la mayor cantidad posible de elementos basados en plantillas del enlace directivo y las funciones del controlador. Esto proporciona otro punto de configuración "similar a la API": ¡el usuario de la directiva puede simplemente reemplazar la plantilla! La funcionalidad permaneció igual, y su API interna nunca se tocó, pero podemos meternos con el estilo y la implementación DOM tanto como sea necesario. ui / bootstrap es un gran ejemplo de cómo hacerlo bien porque Peter y Pawel son increíbles.
Los ámbitos de aislamiento también son excelentes para usar con transclusión. Tomar pestañas; no son solo la funcionalidad completa, sino que lo que sea que esté dentro de él se puede evaluar libremente desde el ámbito principal, dejando las pestañas (y paneles) para hacer lo que quieran. Las pestañas claramente tienen su propio estado , que pertenece al alcance (para interactuar con la plantilla), pero ese estado no tiene nada que ver con el contexto en el que se utilizó: es completamente interno a lo que hace que una directiva de pestañas sea una directiva de pestañas. Además, no tiene mucho sentido usar otras directivas con las pestañas. Son pestañas, ¡y ya tenemos esa funcionalidad!
Rodéelo con más funcionalidad o transcluya más funcionalidad, pero la directiva es lo que ya es.
Dicho todo esto, debo tener en cuenta que existen algunas formas de evitar algunas de las limitaciones (es decir, las características) de un ámbito de aislamiento, como insinuó @ProLoser en su respuesta. Por ejemplo, en la sección de alcance secundario, mencioné la interpolación en la ruptura de atributos no directivos cuando se usa un alcance de aislamiento (por defecto). Pero el usuario podría, por ejemplo, simplemente usar class="item-type-{{$parent.item.type}}"y volvería a funcionar. Entonces, si hay una razón convincente para usar un alcance aislado sobre un alcance secundario pero le preocupan algunas de estas limitaciones, sepa que puede solucionarlas prácticamente todas si lo necesita.
Resumen
Las directivas sin alcance nuevo son de solo lectura; son completamente confiables (es decir, internos de la aplicación) y no tocan el conector. Las directivas con un ámbito secundario agregan funcionalidad, pero no son la única funcionalidad. Por último, los ámbitos de aislamiento son para directivas que son el objetivo completo; son independientes, por lo que está bien (y la mayoría es "correcto") dejar que se vuelvan rebeldes.
Quería expresar mis pensamientos iniciales, pero a medida que pienso en más cosas, actualizaré esto. Pero mierda, esto es largo para una respuesta TAN ...
PD: Totalmente tangencial, pero como estamos hablando de ámbitos, prefiero decir "prototípico", mientras que otros prefieren "prototípico", que parece ser más preciso, pero no sale del todo bien. :-)