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

Question

[Владимир Т.]

Например вместо того, чтобы отдавать результат в контроллер вот так:

<calculate numbers="[5,6]" result=" _переменная_из_$scope_контроллера_ "></calculate>
<concat strings="[ 'hello', 'world' ]" result=" _переменная_из_$scope_контроллера_ "></concat>

оставить только аттрибуты для входных данных (здесь это numbers и strings), а вычисляемый результат отправлять через $scope.$emit.
Обработчик этого события написать сразу в сервис который хранит модель для отправки данных на сервер.
Получится ли таким образом убрать контроллер как посредник между логикой директивы и моделью приложения? Не нарушаю ли я таким образом подход angular-way?

Answer 1

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

Не нарушаю ли я таким образом подход angular-way?

Вы таким образом нарушаете подход MVC. Команды модели может отдавать только контроллер. На дворе 2015-ый год, скоро выйдут angular1.5 и angular2, пора отвыкать от наследия angular1.0 и 1.1

1) никаких $scope в контроллерах (читать про controllerAs). По сути единственное место где можно использовать $scope - link директивы (которых при возможности тоже лучше не юзать). Соответственно такие приятные глазу вещи как $scope.$watch тоже лучше используйте только в link

2) никаких отдельных контроллеров, контроллеры могут быть только у директивы (исключения - тупые контроллеры которые должны замэпить данные из параметров стэйта на директиву, то есть пробросить в атрибуты). Избегать использования module.controller. В целом почитайте про компоненты в контексте angular

3) избегайте использования в приложении начистую angular API. Все то что со знаком $ (например $http, $sce, etc) должно юзаться в обертке (сервисы-репозитории, фильтры, отдельные мини-сервисы...). Таким образом мы максимально отделяем приложение от фреймворка, и делаем поддержку кода проще (например если вы захотите обновить зависимости, вам не придется переписывать пол приложения из-за каких-то изменений в API, ну и сторонние библиотеки тоже рекомендую заворачивать в обертки-фасады, пряча их от приложения. Опять же по той же причине, с ангуляром ждать сюрпризов редко приходится но вот сторонние библиотеки...).

4) передавайте данные явно, то есть никаких ивентов, в сервисы (вашу модель) данные должны попадать по прямому вызову метода из контроллера. Тогда дебаг приложение и тестирование оного (вы же когда-нибудь начнете тестить приложения?) не будут вызывать боли. Да и поддержка кода существенно упростится. Исключение опять же - когда ивенты эмитятся и обрабатываются где-то в сервисах, например когда вы используете web-sockets. Тут как бы все с этим хорошо.

Полезные материалы по теме:

busypeoples.github.io/post/thinking-in-components-...
teropa.info/blog/2014/10/24/how-ive-improved-my-an...

p.s. Это все лишь рекомендации на случай если вы делаете не прототип на коленке а реаьлное приложение. Даже если в ближайшем будущем все это практиковать вам будет не реально (приложение пилится уже давно и переписывать его никто не будет), учтите на будущее.

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

Comments

[Владимир Т.]

Сергей, спасибо за развёрнутый ответ. В дополнение хочу спросить знаком ли вам riotJS? Мне показалось что там именно такой подход к обмену данными в приложении через observable. Что думаете о таком подходе?

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

Владимир Т.: riot это маленькая библиотечка для организации UI (ViewModel по сути), то есть все обработчики событий в его случае должны быть в контроллере или прямо во viewmodel (но лучше в контроллере). На модель riotJS никак не влияет.

Модель вообще должна быть отделена от фреймворка, именно в этом основной профит всех этих MVC/MVVM, независимость ВАШЕГО приложения от СТОРОННИХ решений. Особо хорошо это для тестов и в плане уменьшения рисков/трудозатрат связанных с обновлением библиотек.