Comments 29
В директивах:
   $(this).addClass('test');

Ипользуется jquery. Это вообще «хорошо»?
А. Понял, я думал, тут речь про jQuery вообще.

Если говорить про пример с классами, иногда бывает такое, что, с одной стороны, нужно добавить какой-то класс к элементу, но при этом мы знаем, что это будет происходить только один раз и больше манипуляции с классами не предвидится. В таком случае выводить логику в скоуп действительно не имеет смысла.
«После создания сервисов, наверняка мне захочется воспользоваться ими в контроллерах», которые к роутерам никак не прикручены.
По моим безопытным представлениям, таких контроллеров будет большинство, а через роутер будет 1-2 контроллера.
И тогда толку от этого совета никакого.
Или я чегото недопонимаю?

На мой взгляд, с архитектурой вашего приложения что-то не так.
По моему опыту, контроллеров, «не прикрученных» к роутеру, как раз 1-2 — те контроллеры, которые навешиваются на подгружаемые partial-view с компиляцией на лету (диалоговые окна и т.п.). Все остальные (основные) контроллеры «прикручены» к роутеру.
Конкретно в голове интерфейс такой:
Страница содержит несколько вкладок (табов) по N типов объектов.
Каждая вкладка содержит: тулбар действий, фильтр, таблица обнаруженных объектов, превью выбранного объекта.
Открытие объекта создаёт новую вкладку: тулбар действий, просмотр/редактирование объекта, иногда — таблица связанных/вложенных объектов + тулбар действий с ними.

На рутере у меня, как я понимаю, 2*N контроллеров вкладок (N для «каталогов» и N для отдельных объектов)
А весь остальной ворох — это какраз partial-view, и они могут использовать разные сервисы.
P.S.
¿Или это у меня dojo головного мозга и такие вкладки принято засовывать в один контроллер?
Хорошо, но жаль что не много.
Хочу добавить что ко всем не стандартным аттрибутам лучше добавлять «data-...» или «x-...» дабы не пугать HTML5 валидатор.
Например data-ng-model=..., data-ng-controller=… data-ng-cloak=…
Я для этого при сборке использую плагин для gulp'a под названием gulp-angular-htmlify.
И самому удобнее писать имена директив без data-префикса и валидатор ругаться не будет потом)
Нет-нет, я хотел узнать, проходить валидацию чтобы что? Что мне даст то, что валидатор не ругается? Не сарказм, просто действительно не улавливаю смысла этого.
Скажите, а насколько вообще перспективен этот фреймворк AngularJS? Сейчас стою перед выбором — изучать его или что-то другое, например, Prototype.
Хочу делать SPA, RIA. При этом в качестве серверной платформы планируется старый добрый Django. Не случится ли так, что вскоре декларативный подход, используемый в Angular, будет признан плохой практикой программирования и проект загнётся?
А какая разница, кем и как он будет признан? Вам шашечки или ехать?
Вопрос очень субъективный. Мне нравится, удобно. И я буду пользоваться, даже если его вдруг будут обзывать плохими словами. Если, конечно, не обнаружу что-то лучше. Такой риск есть у любого решения.
Главное чтобы гугл не забросил проект. А они могут, у них дарт есть, и большое желание вывести его в массы.
А если на старый добрый напялить django-rest-framework, то будет достаточно пофиг, что на фронтенде.
http/rest пока умирать точно не собираются.

Ну и ещё, наверное, djangular, чтобы жаваскрипты аккуратно раскладывались
Вы вот упомянули controllerAs, а тему не раскрыли.
А это, как раз, было бы очень интересно. Остальное уже, вроде как, де-факто.
По поводу ngInject — документация к npm-пакету говорит, что «ng-annotate follows references» и такой код

function MyCtrl($scope, $timeout) {
}
var MyCtrl2 = function($scope) {};

angular.module("MyMod").controller("MyCtrl", MyCtrl);
angular.module("MyMod").controller("MyCtrl", MyCtrl2);

будет аннотирован автоматом.
Больше всего понравился трюк с Controller.resolve — действительно, удобно
Скрытый текст
|-- app.js
|-- controllers/
|   |-- MainCtrl.js
|   |-- AnotherCtrl.js
|-- filters/
|   |-- MainFilter.js
|   |-- AnotherFilter.js
|-- services/
|   |-- MainService.js
|   |-- AnotherService.js
|-- directives/
|   |-- MainDirective.js
|   |-- AnotherDirective.js


Не путайте людей. Данный пример (второй из раздела «Структура проекта») — это точно такое же «Плохо», как и предыдущий первый. Подход «структурирование по типу» нельзя использовать даже в проектах с небольшой кодовой базой. Во-первых, маленькие проекты имеют тенденцию вырастать в большие, и вам впоследствии придется делать очень болезненный рефакторинг; во-вторых, это уменьшает пользу от существования единого соглашения по структуризации кода в разных проектах.

«Хорошим» примером является только третий. Причем я бы обязательно добавил, что структура должна быть рекурсивной, а не одноуровневой. Больше чтива по теме из блога разработчиков.
должна быть рекурсивной

я правильно вашу мысль понял?

|-- app.js
|-- dashboard/
|   |--controllers/
|   |   |-- DashboardCtrl.js
|   |--services/
|   |   |-- DashboardService.js
|-- login/
|   |--services/
|   |   |-- LoginService.js
|   |--controllers/
|   |   |-- LoginCtrl.js
|-- inbox/
|   |--services/
|   |   |-- InboxService.js
|   |--controllers/
|   |   |-- InboxCtrl.js
Нет, элементом рекурсии является кусок функциональности проекта (feature), а не тип сущности. Подробнее об этом по ссылке, что я привел выше.
Only those users with full accounts are able to leave comments. Log in, please.