Для чего и как применять директивы в AngularJS?

Question

[Alexey Sosnovsky]

В данный момент изучаю Angular и честно говоря плохо понимаю для чего нужны директивы и где их применять. Вмоём текущем понимании это всего лишь кусок кода и шаблон, но тогда почему не пользоваться например ng-inject и работать в нём при помощи контроллера. Вобщем, подскажите пожалуйста, умудрённые опытом люди, где и как и в каком виде правильно и разумно применять директивы? Будет вдвойне полезней если ещё и ссылки на примеры накидаете.

Answer 1

[Сергей Протько]

для чего нужны директивы

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

где их применять

Везде где только можно, весь UI следует строить на иерархии директив, как если бы вы просто верстали. Я бы даже сказал что использовать только контроллер, как например можно увидеть в примерах для ngRoute/uiRouter и шаблон - это плохо, контроллеры и шаблоны использовать можно, но только для того что бы определить какие в рамках этого роута/стэйта будут использоваться директивы и передать туда параметры. То есть по максимуму все запихивать в директивы. Правда это может быть первое время сложно делать, потому лучше постепенно увеличивать степень дробления UI на директивы. Главная сложность сделать так, что бы директивы были независимы от контекста использования. Ну или явно определить этот контекст (параметр require директивы может определять что директива A может быть использована или должна быть использована только в контексте B). Ну и еще по началу может быть сложно определиться что должно быть в link и что должно быть в контроллере, должен ли вообще у директивы быть link или контроллер.

ng-inject

вы про галповский плагин или все же про ng-include? если последнее, как комбинация ng-include + ng-controller, то это тип... для ленивых. При помощи этих двух директив мы можем создать какой-то элемент, присобачить ему поведение и шаблон, да, но оно не будет изолированным, реюзать такое уже не выйдет. Если это вам надо временно, и вам лень - то можно и так, но лучше сделать полноценную директиву, тогда ее можно будет реюзать в рамках проекта и устранить дублирование. Ну и опять же, вариант с ng-include+ng-controller можно покрыть только E2E тестами, что не удобно. Директивы же просто и удобно покрываются юнит тестами, что делает поддержку системы намного проще и дешевле.

в каком виде правильно и разумно применять директивы

Посмотрите на polymer, это то чем должны были бы стать директивы а ангуляре (и в angular2 оно почти так), там больше ограничений и более понятно как использовать web-компоненты и как следствие - директивы.

Comments

[copal]

Неоднократно вижу, как Вы утверждаете что angular это не mvc-framework. У второй версии об этом даже нигде не упоминается. И от сюда вопрос - а что тогда использовать для архитектуры на клиенте? Почему гугл всегда ведет в пропасть? Зачем нужны компоненты, когда скоро появится webassambler и все кому не лень, будь-то adobe или microsoft, смогут и скорее всего и сделают отдельный язык, в котором не будет не html не css, черт их побери. И почему всегда ставят на гугл, когда у него самое большее соотношение провальных-ведущих в никуда проектов?

[Сергей Протько]

copal: почему же не MVC фреймворк? Очень даже MVC, но помимо MVC он еще HMVC и MVVM предоставляет.

[Сергей Протько]

copal: писал с утра, не проспавшись. Так это, что у вас там за истерия по поводу гугла и его провальности?

1) webassembly это стандартизированный ASM.js. И только. Заменить DOM пока не выйдет.
2) никто н гугл не ставит, гугл имеет непосредственное отношение к полимеру и ангуляру, но там много уже и от комьюнити, для меня это просто удобные инсртументы. Если в один прекрасный день перестану поддерживать ангуляр (маловероятный сценарий, уж слишком много людей его тыкало), то я лично просто перейду на что-то другое. В контексте модульного angular2 это сделать очень легко и просто.

[vasIvas]

Сергей Протько: а я хоть и не в тему, но тоже выскажусь. AngularJS - мутноватая тема. Все что он делает, это берет с dom элемент и предоставляет на него ссылку, которою нужно получить написав тысячу строк вместо одной dom.getElement. Все.

Я новичок в вэбе и не сделал ещё ни одного сайта, но цель моя и не они. Я пришел сюда чтобы применить знания полученные в gamedev в "мегасайтах", которые будут на половину состоять из canvas либо svg. Оговорюсь сразу, что можно было бы и на все сто процентов, но это много чего можно, но не значит лучше. И так вот когда я думаю о завтра, то начинаю сомневаться, что для правильного spa мне нужен angular. Ведь он может помочь только с dom, но не как не с canva (не знаю о svg по этому буду говорить только о canvas). Ведь для использования canvas мне нужно так же mvc, но не то компонентное, которое angular предоставляет.
По этому вывод - он только для микроприложений построенных.

И ещё он не нравится тем, что в нем отсутствует модель. Да, есть контроллер, котрый можно использовать как viewModel, но модели так и нет. Данные, которые должны находится в модели, размазаны по сервисам, а то и того хуже, фабрикам, что в свою очередь превращает программирование в процедурное.
Да, фабрика может хранить данные, сервис же должен только обрабатывать их (получать или что-то с ними делать), но в тот момент, когда я в viewModel'е хочу начать с ними работать, я должен их подтягивать из модели. Нет классической (от слова классика) модели, нет mvc.
А hmvc это нечто! Зачем вводить слой для связи контроллеров, когда они и так прекрасно общаются через mainController при помощи событий.
Вот частенько всплывают вопросы, можно ли одному контроллеру обрабатывать несколько моделей. И все говорят можно. И вот на мой взгляд упоминание о hmvc говорит лишь о том, что кто-то не столь умный не стал у чуваков спрашивать "а можно ли контроллеры будут общаться", а сразу написал о этом статью.

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

[vasIvas]

Сергей Протько: но так же добавлю, что я все равно буду им пользоваться, но не хотел бы его пожелать себе в самом начале пути. Он весь мозг вынесет. Ведь отсылать запросы из фабрики, как это делают многие, это вообще равносильно ходьбе по потолку. angular, который уже очень часто советуют вместо jQ будет идти только во вред.

[Сергей Протько]

vasIvas: Вы видимо никогда не писали ничего более-менее больного на каком-нибудь backbone в былые времена…

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

Ну вот не надо утрировать, ссылка на элемент это самый минимум того что он делает. По факту:

предоставляет структуру для инкапсуляцию поведения элемента (контроллер для поведения, link для инфраструктуры и работы с dom)
изоляция от внешнего мира (изолированный scope, прообраз данных через атрибуты)
шаблоны
иерархия и выполнение директив согласно приоритетам (хотя это сомнительно, обычно соль именно в иерархии и ngTransclude).
И это только в контексте того, что дают нам директивы. Не забываем про внедрение зависимостей, добротный низкоуровневый сервис для работы с сетью… и все все все все можно покрывать юнит тестами. Вы когда-нибудь пробовали покрывать тестами приложение на голом jquery с этими вот getElement и т.д.? Это боль и унижение, потому так мало пишут тестов под это дело, только E2E спасает а их поддерживать сложнее.

применить знания полученные в gamedev в "мегасайтах",

И вот вопрос, вы говорите о мегасайтах, SPA и т.д. а потом сразу спрыгиваете обратно в gamedev. SVG, canvas и т.д. - это все части отдельных элементов UI, к SPA это вообще никак не относится. SPA это сайты аля google music или... да вот тот же тостер можно вполне себе сделать как SPA. А то о чем вы говорите - это игрушки, для этого есть свои фреймворки. Каждой задаче свой инструмент.

И ещё он не нравится тем, что в нем отсутствует модель.

Из коробки ничего для организации этого слоя нет, согласен, это минус. С другой стороны - есть все что нужно для организации сервисного слоя, а далее уже пляшите как хотите. Мне вот нравится js-data, кому-то нравится backbone для моделек, кто-то берет restangular или что-то в этом духе... Как по мне дать возможность разработчику самому решить как у него будет организована модель - это есть хорошо. Для меня ангуляр решает огромную проблему в плане организации конкретно UI layer + предоставляет неплохой слой инфраструктуры (если рассматривать вместе с готовыми решениями а не только то что идет из коробки).

а то и того хуже, фабрикам

Это уж как вы сами сделаете. Фабрики в ангуляре нужны только для того что бы создать сервис. Если вы храните там данные - это конкретно ваша проблема. Большинство это делают там, согласно шаблону "модуль", таким образом добиваются инкапсуляции и изоляции данных. Но это не значит что люди хранят данные в "фабрике". я вот фабрики вообще не пользую. Имхо это больше не понимание проблемы с вашей стороны. Попробуйте совместить шаблон "модуль" и шаблон "фабрика". Получите то же самое.

А hmvc это нечто! Зачем вводить слой для связи контроллеров, когда они и так прекрасно общаются через mainController при помощи событий.

Вы о чем вообще? Причидите пример, о каких событиях вы тут толкуете, нет там ничего такого. События аля $destroy у скоупа это системные события, да и вообще общение через события дурная идея. Мне кажется вы просто не знаете о чем говорите либо я вас не понимаю. Привидите пример того что вас напрягает в этом контексте и я на 99% скажу что либо вы не верно поняли (я подозреваю что вы про ngModelController?) либо просто сами так сделали.

Вот частенько всплывают вопросы, можно ли одному контроллеру обрабатывать несколько моделей.

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

Скоро забудем о ооп

если ООП для вас это шаблоны и прочее - то лучше такое ООП забыть и учить по новой. Для меня ООП это набор принципов и правил, которые причем иногда можно нарушить в угоду удобству (покажите мне людей которые сегодня используют каконическую реализацию абстрактной фабрики, там где не нарушается LSP, я думаю сейчас это редко можно встретить)

Ведь отсылать запросы из фабрики

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

[Сергей Протько]

vasIvas: сори, не привык с мобильника печатать... там в первой половине много опечаток аля "прообрас -> проброс"

[vasIvas]

Сергей Протько:

а потом сразу спрыгиваете обратно в gamedev. SVG, canvas и т.д. - это все части отдельных элементов UI, к SPA это вообще никак не относится

Возможно я неправильно понимаю spa, но в моем понятии, это когда рендер происходит на клиенте и нет перезагрузки страницы. И если это так, то мог бы предположить что возможно я и больше Вашего понимаю, ведь я же все-таки из флеша сюда пришел. Если Вы скажите что флеш это какое-то детское недоразумение, то я могу сказать ли что typescript, это жалкое подобие as3, а js только лет через пятьдесят станет таким же как as3. И это к тому, что пока он таким станет, он может стать даже хуже. as3 высокоуровневый ооп язык, который впитал в себя лучшее от всех существующих. Этот язык намного серьезней чем js + html + css и все что с ним связанно. Многие даже не понимают что приложения на их телефонах сделаны на том же языке что и в браузерах. Ведь он компилируется под все платформы. И это уже все доступно с 2007 года. В js этот минимум будет только лет через десять. А сокеты я использовал ещё тогда, когда в js о них и не слышали.
А когда я слышу о компонентах, то мне становится смешно о том, какими их видят web программисты и на сколько они далеки от понимания правильности, которая уже сто лет в as3.

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

И canvas и svg, это не игры. Что если я захочу сделать 3d сайт или супер интерактив. То почему это будет игрой, если так же будут и обычные элементы, как комментарии и прочие? И почему это не будет spa? И получается что я хочу сделать spa, а angular, который для spa не справляется.

И можно подробней о моделях из backbone и js-data, а то мне очень интересно, но не понятно.

[Сергей Протько]

vasIvas: SPA это single page application, по сути это эдакое название для обычного (ну или толстого) клиента в контексте клиент-серверной архитектуры, то что оно single page означает только то что есть одна точка входа и все.

Скажем в контексте того, чем занимаюсь я, это всякого-рода бизнес приложения. Например... вконтактики можно рассматривать как SPA, или gmail. Да даже тостер может быть реализован как SPA, для конечного пользователя разницы не будет, SPA это или просто сайт. Функционировать он будет схожим образом, просто сервер будет только данные предоставлять и ничего не будет знать о клиенте.

Теперь канвасы и SVG - это маленький кусочек того, что нам предлагают DOM API и браузеры. Скажем на SVG удобно графики строить, на canvas можно игрушки делать (хотя лучше на webgl), или с картинками баловаться... или еще чего. По сути это очень узко специализированные вещи. Одно для работы с растром, другое для работы с вектором. Для работы с этими вещами существуют отдельные библиотеки.

Давайте возьмем игрушку, у нас есть какое-то прилоежение-игрушка, на canvas/webgl. Это один элемент и куча логики поверх него + обработка DOM ивентов и т.д. То есть наше приложение-игрушка это лишь один компонент в контексте SPA, а не все SPA. Ангуляр вам тут поможет только в одном - изолирует это в директиву, а внутри делайте уже что хотите. Все что будет происходит с канвасами выходит за рамки того, для чего делался ангуляр. Он может вам предоставить сервисный слой для логирования, для работы с сетью... и все. UI - уже ваша забота в контексте этой задачи. Возможно у вас будут еще какие-то странички или отдельные состояния - тут ангуляр тоже может помочь, но с самой игрушкой - нет, не для того ангуляр делался.

3D сайт - хороший пример. Что именно у вас будет 3D? Переходы по страницам в стиле "куб"? Так не вопрос, у вас есть директива изолирующая вьюпорт состояний, и вы можете довешивать на него дополнительную логику, которая скажем запускает анимацию по переходу на другое состояние. А еще мы можем дописать директиву которая сохраняет текущее состояние в кеш (примерно так сделали чуваки из ionic-а для оптимизаци перехода по скринам). Причем canvas/svg тут не нужны - все это можно делать через css. Если же вы хотите выйти за пределы DOM и отрисовывать все на canvas (как если бы мы работали с flash/flex) - то это опять же выходит за пределы ответственности ангуляра. Тут вам кое как может помочь ReactJS, так как он как раз таки предоставляет абстракцию над UI, и вы можете под копотом юзать хоть стандартный DOM, хоть свой движек на canvas/webgl. И опять же, вы можете использовать reactjs внутри ваших директив на ангуляре - это не запрещается.

Вернемся к ивентам. Мне не нравятся ивенты там, где можно обойтись без них. Если у вас происходит общением между только двумя элементами системы, ивенты использовать не имеет смысла. Лучше явно вызывать методы. Опять же, хороший пример - ngModelController, он позволяет регистрировать свои обработчики, которые выполняются по цепочке. Почти-что цепочка ответственности.

В вашем случае, помниться, вы пытались организовать общение контроллера плеера и контроллера элементов управления этого плеера. При том что в этом случае нам нужно общение только вверх (от элементов управления к плееру), я не вижу причин вводить тут ивенты. Единственно что, плеер может уведомлять скоуп об изменении своего состояния (например пользователь нажал паузу, но другим способом а не нажатием на кнопку). Это удобно, да. Но в целом все зависит от ситуации. Конкретно ангуляр вам никак не регламентирует как должны общаться директивы между собой. Я лично стараюсь избегать ивентов если могу, ибо их намного сложнее тестировать чем простой вызов метода мок-объекта.

Ну и по поводу моделей. backbone позволяет организовать мэппинг данных на клиенте на api по типу active record, ну и в теории можно организовать на его основе трехсторонний дата биндинг но я по такому не угараю, js-data - что-то типа data-mapper, более универсальное решение для организации persistence layer ваших моделей. Модель в этом случае будет представлена совокупностью POJO (Plain Old Javascript Object), сервисов и т.д. Но это в контексте именно приложений. Это бизнес логика этих приложений. Для меня модель это именно это, и ее не может быть много, это просто слой.

Ну и да, я не считаю что флеш это детское недоразумение, работал с ним лет 6-7 назад так как альтернативы что-то забавное делать небыло. По поводу TypeScript жалкое подобие AS3 - это уже лучше чем было ранее, согласитесь, JS так себе язык. AS3 клевая штука но флэш/флекс как платформа уже не нужны (почти).

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