Моя личная политика и опыт:

Изолирован: отдельная песочница

Я хочу создать множество методов и переменных области, которые ТОЛЬКО используются моей директивой и никогда не видны или напрямую не доступны пользователю. Я хочу, чтобы белый список доступных мне данных. Я могу использовать переход, чтобы позволить пользователю вернуться в родительскую область (без изменений). Я НЕ хочу, чтобы мои переменные и методы были доступны для заблокированных детей.

Ребенок: подраздел содержимого

Я хочу создать методы и переменные области, которые CAN будет доступен пользователю, но не имеют отношения к окружающим областям (родным и родителям) вне контекста моей директивы. Я также хотел бы, чтобы данные родительской области полностью просачивались прозрачно.

Нет: простые, доступные только для чтения директивы

Мне действительно не нужно возиться с методами или переменными области. Я, вероятно, делаю то, что не связано с областями (например, отображение простых плагинов jQuery, проверка и т.д.).

Примечания

• Вы не должны позволять ngModel или другим вещам напрямую влиять на ваше решение. Вы можете обойти нечетное поведение, делая такие вещи, как ng-model=$parent.myVal (дочерний) или ngModel: '=' (изолировать).
• Изоляция + transclude приведет к восстановлению всех нормальных действий директиву сиблинга и возвращается в родительскую область, поэтому не позволяйте этому влиять и на ваше мнение.
• Не связывайтесь с областью действия none, потому что это похоже на помещение данных в область для нижней половины DOM, но не в верхнюю половину, которая имеет смысл 0.
• Обратите внимание на приоритеты директив (у вас нет конкретных примеров того, как это может повлиять на вещи).
• Ввести службы или использовать контроллеры для связи по директивам с любым типом области. Вы также можете сделать require: '^ngModel' для просмотра в родительских элементах.

После написания многих директив я решил использовать меньше isolated. Несмотря на то, что это круто, и вы инкапсулируете данные и не пропустите утечку данных в родительскую область, это сильно ограничивает количество директив, которые вы можете использовать вместе. Итак,

Если директива, которую вы собираетесь написать, будет вести себя полностью сама по себе, и вы не собираетесь делиться ею с другими директивами, идите в изолированную область. (например, компонент, который вы можете просто подключить к нему, с небольшой настройкой для конечного разработчика) (становится очень сложно, когда вы пытаетесь записать подэлементы, в которых есть директивы)

Если директива, которую вы собираетесь писать, будет просто делать манипуляции с dom, которая не нуждается в внутреннем состоянии области видимости или явных изменениях в сфере (в основном, очень простые вещи); не ищите новых областей. (например, ngShow, ngMouseHover, ngClick, ngRepeat)

Если директива, которую вы собираетесь писать, должна изменить некоторые элементы в родительской области, но также должна обрабатывать некоторое внутреннее состояние, перейдите к новой области содержимого. (например, ngController)

Обязательно проверьте исходный код для директив: https://github.com/angular/angular.js/tree/master/src/ng/directive
Это очень помогает в том, как думать о них.

Просто подумал, что добавлю свое нынешнее понимание и как оно относится к другим концепциям JS.

Значение по умолчанию (например, не объявлено или область: ложь)

Это философски эквивалентно использованию глобальных переменных. Ваша директива может получить доступ ко всему в родительском контроллере, но она также затрагивает их и подвергается воздействию одновременно.

Объем: {}

Это похоже на модуль, все, что он хочет использовать, необходимо передать явно. Если директива EVERY, которую вы используете, является областью изоляции, она может быть эквивалентна созданию КАЖДОГО JS файла, который вы пишете свой собственный модуль с большим количеством накладных расходов при инъекции всех зависимостей.

область: дочерний

Это промежуточная точка между глобальными переменными и явной транзитной пересылкой. Он похож на цепочку прототипов javascript и просто расширяет вашу копию родительской области. Если вы создаете область изоляции и передаете каждый атрибут и функцию родительской области, она функционально эквивалентна этому.

Ключ в том, что ЛЮБАЯ директива может быть написана ЛЮБОЙ путь. Здесь вы можете различать различные объявления областей, которые помогут вам организовать. Вы можете сделать все модули, или вы можете просто использовать все глобальные переменные и быть очень осторожными. Для удобства обслуживания, хотя предпочтительнее модулярность вашей логики в логически когерентные части. Существует баланс между открытым лугом и закрытым тюремным залом. Причина, по которой это сложно, я считаю, что когда люди узнают об этом, они думают, что они узнают о том, как работают директивы, но на самом деле они изучают организацию кода/логики.

Еще одна вещь, которая помогла мне разобраться, как работают директивы, - это узнать о ngInclude. ngInclude позволяет включать частичные части html. Когда я впервые начал использовать директивы, я обнаружил, что вы можете использовать его вариант шаблона, чтобы уменьшить свой код, но я действительно не добавлял какую-либо логику.

Конечно, между директивами angular и работой команды angular-ui мне еще не приходилось создавать свою собственную директиву, делает что-то существенное, поэтому мой взгляд на это может быть совершенно неправильным.

Я согласен с Умуром. Теоретически, изолированные области звучат замечательно и "переносимы", но при создании моего приложения для привлечения нетривиальной функциональности мне пришла в голову необходимость включения нескольких директив (некоторые вложенные внутри других или добавления атрибутов к ним), чтобы полностью написать в моем собственный HTML-код, который является целью определенного для домена языка.

В конце концов, слишком странно передавать каждое глобальное или общее значение в цепочку с несколькими атрибутами при каждом вызове DOM директивы (как это требуется с областью выделения). Он просто выглядит немым, чтобы многократно писать все это в DOM, и он чувствует себя неэффективно, даже если это общие объекты. Это также излишне усложняет декларации директив. Обходной путь использования $parent для "достижения" и получения значений из директивы HTML кажется очень плохим.

Я тоже запустил изменение своего приложения, чтобы иметь в основном директивы для дочерних областей с очень небольшим количеством изолятов - только те, которые не нуждаются в доступе к НИЧЕГО от родителя, кроме того, что они могут быть переданы простым, неповторяющимся атрибуты.

С тех пор, как я мечтал о мечтах о доменных специфических языках за десятилетия до того, как появилась такая вещь, я был в восторге от того, что AngularJS предоставляет этот вариант, и я знаю, что, поскольку больше разработчиков работают в этой области, мы увидим некоторые классные приложения, которые также легко для их архитекторов писать, расширять и отлаживать.

- D