как написать директиву в angularjs, как мне решить, не нужна ли мне новая область, новая дочерняя область или новая изолированная область?

<p>я ищу некоторые рекомендации, которые можно использовать, чтобы помочь определить, какой тип области применения использовать при написании новой директивы. в идеале мне бы хотелось что-то похожее на блок-схему, которая проведет меня через кучу вопросов и выдаст правильный ответ - без новой новой области, новой дочерней области или новой изолированной области - но это, вероятно, требует слишком многого. вот мой текущий мизерный набор рекомендаций:</p><ul> <li>не используйте изолированную область видимости, если элемент, который будет использовать директиву, использует модель ng<br> смотрите <a href="https://stackoverflow.com/questions/11896732/ngmodel-and-component-with-isolated-scope">могу ли я использовать ng-модель с изолированной областью действия?</a> и<br> <a href="https://stackoverflow.com/questions/14495882/why-formatters-does-not-work-with-isolated-scope">почему форматеры не работают с изолированной областью действия?</a> </li> <li>если директива не изменяет какие-либо свойства области/модели, не создавайте новую область</li> <li>области изолята, кажется, работают хорошо, если директива инкапсулирует набор элементов dom ( <a href="http://docs.angularjs.org/guide/directive">документация</a> говорит, что "сложная структура dom") и директива будет использоваться как элемент, или без других директив на тот же элемент.</li> </ul><p>мне известно, что использование директивы с изолированной областью действия для элемента заставляет все другие директивы в том же элементе использовать одну и ту же (одну) изолированную область действия, так что, не может ли это серьезно ограничить возможность использования изолированной области действия?</p><p>я надеюсь, что некоторые из команды angular-ui (или другие, которые написали много директив) могут поделиться своим опытом.</p><p>пожалуйста, не добавляйте ответ, который просто говорит: "используйте изолированную область для повторно используемых компонентов".</p>

<p>какой замечательный вопрос! я <em>люблю</em> слышать, что говорят другие, но вот рекомендации, которые я использую.</p><p>высотная предпосылка: scope используется в качестве "клея", который мы используем для связи между родительским контроллером, директивой и шаблоном директивы.</p><p><strong>родительская область:</strong> <code>scope: false</code>, так что никакой новой области вообще нет</p><p>я использую это не очень часто, но, как сказал @markrajcok, если директива не обращается к каким-либо переменным области видимости (и, очевидно, не устанавливает их!), то, на мой взгляд, это нормально. это также полезно для дочерних директив, которые <em>only</em> используются в контексте родительской директивы (хотя из этого всегда есть исключения) и которые не имеют шаблона. по сути, все, что связано с шаблоном, не имеет общей области видимости, потому что вы по своей сути выставляете эту область для доступа и манипулирования (но я уверен, что есть исключения из этого правила).</p><p>в качестве примера я недавно создал директиву, которая рисует (статическую) векторную графику с использованием библиотеки svg, которую я нахожусь в процессе написания. он <code>$observes два атрибута (width и height) и использует их в своих вычислениях, но он не устанавливает и не читает никакие переменные области и не имеет шаблона. это хороший вариант использования, чтобы не создавать другую область; нам это не нужно, так зачем?но в другой директиве svg мне потребовался набор данных, который нужно было использовать, и, кроме того, я должен был хранить крошечную информацию о состоянии. в этом случае использование родительской области было бы безответственным (опять же, вообще говоря). так что вместо ...<strong>child scope:</strong> scope: trueдирективы с дочерней областью являются контекстно-зависимыми и предназначены для взаимодействия с текущей областью.очевидно, что ключевым преимуществом этого по сравнению с изолированной областью является то, что пользователь может свободно использовать интерполяцию для любых атрибутов, которые они хотят; например использование class="item-type-{{item.type}}" в директиве с изолированной областью не будет работать по умолчанию, но прекрасно работает на директиве с дочерней областью, потому что все, что интерполировано, все еще по умолчанию можно найти в родительской области. кроме того, сама директива может безопасно оценивать атрибуты и выражения в контексте своей собственной области, не беспокоясь о загрязнении или повреждении родительского объекта.например, всплывающая подсказка - это то, что просто добавляется; изолированная область не будет работать (по умолчанию, см. ниже), потому что ожидается, что здесь мы будем использовать другие директивы или интерполированные атрибуты. подсказка - это просто улучшение. но всплывающая подсказка также должна установить некоторые вещи в области действия для использования с под-директивой и/или шаблоном и, очевидно, для управления своим собственным состоянием, так что было бы действительно плохо использовать родительскую область действия. мы либо загрязняем его, либо наносим ущерб, и ни один не является буэно.я чаще использую детские прицелы, чем одиночные или родительские.<strong>изолировать область действия:</strong> scope: {}это для многоразовых компонентов. :-)а если серьезно, я думаю о "повторно используемых компонентах" как о "автономных компонентах". намерение состоит в том, что они должны использоваться для определенной цели, поэтому объединение их с другими директивами или добавление других интерполированных атрибутов к узлу dom по своей сути не имеет смысла.чтобы быть более конкретным, все, что необходимо для этой автономной функциональности, предоставляется через определенные атрибуты, оцениваемые в контексте родительской области; это либо односторонние строки ('@'), либо односторонние выражения ('&'), либо двусторонние привязки переменных ('=').на автономные компоненты не имеет смысла применять другие директивы или атрибуты, потому что он существует сам по себе. его стиль регулируется собственным шаблоном (при необходимости) и может включать соответствующий контент (при необходимости). он автономен, поэтому мы помещаем его в изолированную область также, чтобы сказать: "не связывайтесь с этим. я даю вам определенный api через эти несколько атрибутов".хорошей практикой является исключение как можно большего количества материалов на основе шаблонов из ссылки директивы и функций контроллера. это обеспечивает другую "api-подобную" конфигурационную точку: пользователь директивы может просто заменить шаблон! все функциональные возможности остались прежними, и его внутренний api никогда не затрагивался, но мы можем связываться со стилем и реализацией dom столько, сколько нам нужно. ui/bootstrap - это отличный пример того, как сделать это хорошо, потому что питер и павел потрясающие.области применения изолятов также отлично подходят для использования с включением. взять вкладки; они представляют собой не только всю функциональность, но все, что является внутри этой функцией, можно свободно оценить изнутри родительской области, оставляя вкладки (и панели), чтобы делать все, что они хотят. вкладки явно имеют свой собственный state, который принадлежит области (для взаимодействия с шаблоном), но это состояние не имеет ничего общего с контекстом, в котором оно использовалось - оно полностью внутреннее для того, что делает директива табуляции директива табуляции. кроме того, не имеет смысла использовать какие-либо другие директивы с вкладками. это вкладки - и мы уже получили эту функциональность!окружите его большей функциональностью или включите больше функциональности, но эта директива уже есть.из всего сказанного следует отметить, что существуют некоторые способы обойти некоторые ограничения (то есть особенности) изолированной области видимости, как намекал @proloser в своем ответе. например, в разделе дочерней области я упомянул интерполяцию при разрыве ненаправленных атрибутов при использовании изолированной области (по умолчанию). но пользователь может, например, просто использовать class="item-type-{{$parent.item.type}}"</code>, и он снова будет работать. поэтому, если есть веская причина использовать изолированную область над дочерней областью, но вы беспокоитесь о некоторых из этих ограничений, знайте, что при необходимости вы можете обойти практически все из них.</p><p><strong>summary</strong></p><p>директивы без новой области видимости доступны только для чтения; им полностью доверяют (то есть внутри приложения) и они не касаются гнезда. директивы с дочерней областью действия <em>add</em>, но они не являются <em>единственной</em> функциональностью. наконец, отдельные области действия предназначены для директив, которые являются всей целью; они автономны, так что можно (и наиболее "правильно") отпустить их изгоев.</p><p>я хотел высказать свои первоначальные мысли, но, как я думаю о большем количестве вещей, я буду обновлять это. но, черт возьми, - это долго для ответа so ...</p><hr><p>ps: абсолютно тангенциальный, но поскольку мы говорим о сферах, я предпочитаю говорить "прототип", тогда как другие предпочитают "прототип", который кажется более точным, но просто скатывается с языка совсем не хорошо. :-)</p>

<h1>моя личная политика и опыт:</h1><h2>изолированный: <em> личная песочница </em></h2><p>я хочу создать множество методов и переменных области видимости, которые используются только в моей директиве и никогда не видны и не доступны напрямую пользователю. я хочу добавить в белый список данные о том, что мне доступно. <strong>я могу использовать transclusion, чтобы позволить пользователю вернуться в родительскую область (без изменений)</strong>. я <strong>не</strong> хочу, чтобы мои переменные и методы были доступны для включенных детей.</p><h2>ребенок: <em> подраздел контента </em></h2><p>я хочу создать методы и переменные области видимости, которые <strong>могут</strong> доступны для пользователя, но не имеют отношения к окружающим областям (родным братьям и родителям) вне контекста моей директивы. я также хотел бы, чтобы все родительские данные области видимости просачивались прозрачно.</p><h2>нет: <em> простые директивы только для чтения </em></h2><p>мне действительно не нужно связываться с методами или переменными области видимости. я, вероятно, делаю что-то, что не связано с областями действия (например, отображение простых плагинов jquery, проверка и т.д.).</p><h1>заметки</h1><ul> <li>вы не должны позволять ngmodel или другим вещам напрямую влиять на ваше решение. вы можете обойти странное поведение, используя такие вещи, как <code>ng-model=$parent.myval (дочерний) или ngmodel: '=' (изолировать). <strong>isolate</strong> + <strong>transclude</strong> восстановит все нормальное поведение в директивах одного уровня и вернет родительскую область видимости, поэтому не позволяйте этому влиять на ваше суждение. не связывайтесь с областью действия <strong>none</strong>, потому что это похоже на размещение данных в области видимости для нижней половины dom, но не для верхней половины, что имеет смысл 0. обратите внимание на приоритеты директив (не приводите конкретных примеров того, как это может повлиять на ситуацию) внедрить сервисы или использовать контроллеры для связи через директивы с любым типом области вы также можете сделать require: '^ngmodel', чтобы посмотреть в родительских элементах. 

после написания большого количества директив я решил использовать меньше isolated scope. несмотря на то, что это круто, вы инкапсулируете данные и не пропускаете данные в родительскую область, но это серьезно ограничивает количество директив, которые вы можете использовать вместе. так,если директива, которую вы собираетесь написать, будет вести себя <strong> полностью </strong> сама по себе, и вы не собираетесь делиться ею с другими директивами, перейдите к  изолированная область видимости . (как компонент, который вы можете просто подключить, без особой настройки для конечного разработчика) (становится очень хитрее, когда вы пытаетесь написать подэлементы, которые имеют директивы внутри)если директива, которую вы собираетесь написать, собирается  просто  делать dom-манипуляции, для которых не требуется внутреннее состояние области видимости или явные изменения области видимости (в основном очень простые вещи); перейти на  нет новой области . (например, ngshow, ngmousehover, ngclick, ngrepeat)если директива, которую вы собираетесь написать, должна изменить некоторые элементы в родительской области, но также должна обрабатывать некоторое внутреннее состояние, перейдите к  новой дочерней области . (например, ngcontroller)обязательно ознакомьтесь с исходным кодом директив: <a href="https://github.com/angular/angular.js/tree/master/src/ng/directive">https://github.com/angular/angular.js/tree/master/src/ng/directive  это очень помогает о том, как думать о них

я согласен с умуром. теоретически, изолированные области видимости прекрасны и "переносимы", но при создании моего приложения для использования нетривиальной функциональности я столкнулся с необходимостью включить несколько директив (некоторые вложенные в другие или добавление к ним атрибутов), чтобы полностью писать в моем собственный html, который является целью специфичного для домена языка.в конце концов, это слишком странно - передавать каждое глобальное или общее значение по цепочке с несколькими атрибутами при каждом вызове dom директивы (как это требуется для изолированной области). просто выглядит глупо многократно записывать все это в dom, и это кажется неэффективным, даже если это общие объекты. это также излишне усложняет декларации директивы. обходной путь использования $ parent для "охвата" и получения значений из директивы html выглядит как очень плохая форма.</p><p>я также закончил тем, что изменил свое приложение, чтобы иметь в основном дочерние директивы области видимости с очень небольшим количеством изолятов - только те, которым не требуется доступ ничего от родителя, кроме того, что они могут быть переданы через простые неповторяющиеся атрибуты.</p><p>я десятилетиями мечтал о мечте о предметно-ориентированных языках до того, как это произошло, я воодушевлен тем, что angularjs предоставляет эту опцию, и я знаю, что, поскольку в этой области будет работать больше разработчиков, мы увидим несколько очень интересных приложений, которые их архитекторам также легко писать, расширять и отлаживать.</p><p>- d</p>