Разделяй и властвуй или как сделать ваше приложение структурированным

[Fesor]

В чем смысл делать модули вида app.controllers да еще и каждый контроллер в отдельный модуль оборачивать? Мне казалось что лучше разделить приложения на модули исходя их функционала, объединить все общие части в один модуль и тд. Все что может реюзаться вне контекста проекта так же можно выносить… но вот так вот просто app.controllers — может для небольших приложений и годится но… По поводу ваших доводов, я просто каждый контроллер выношу в отдельный файл, а дальше в дело вступают сборщики, ватчеры и т.д. В идеале модули должны быть максимально самодостаточными и иметь явные зависимости.

[xGromMx]

Так приложение становится более структурированным, ясное дело, что после сборщика все будет выглядить как один файл, но для дебага очень даже не плохой подход.

[Fesor]

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

[xGromMx]

Ну так этого никто не отменял, просто еще одна директория с теми подмодулями.

[Fesor]

директории как по мне достаточно

[xGromMx]

посмотрите предидущий пост по ng, вот там все убивается, даже само понятие good code.

[xGromMx]

создаете отдельные папки с названием модуля, типа user а в нем сервисы, директивы и прочее.

[xGromMx]

Окей, я попробую объснить почему это удобно. Есть такой модуль как ui-route. У него есть state. В нашем приложении есть основной main.js а также папка юзер (наш сабмодуль или же пакет). В нем есть все, что я писал выше + partials. Наш state будем допустим user.list что есть в нашем модуле user как list.html. Это дает прозрачно посмотреть откуда шаблон и какой модуль. Так можно делать много разных модулей. Я просто хотел сделать проще подход к разработке. И теперь наш модуль с контроллерами будет как app.user.controllers и контроллер app.user.controllers.UserListCtrl. Как по мне я могу прозрачно увидеть структуру. Это я об сложных приложениях. Таже есть папка common и vendor. Common содержит общие директивы и прочие вещи, а vendor это bower пакеты. Это мое решение, и оно мне нравится. Каждое решение имеет право на существование.

[dark_ruby]

напишите про angularjs с requirejs

[xGromMx]

Дабы не быть голословным вот набросал немного github.com/xgrommx/angular-structure

За код сильно не пинайте, писал очень быстро.

[Demetros]

Скажите, чем вам не нравится ng-boilerplate?

[iximiuz]

Просто оставлю это здесь github.com/mgechev/angularjs-style-guide.

[olegdunkan]

«Что это нам дает? Ну одно из преимуществ, то что тут нет angular watcher’ов.»

<div ng-click="main.logger('Test for a one value')">{{ main.nonObservableVar.one }}</div>
<div ng-click="main.logger('Test for a two value')">{{ main.nonObservableVar.two }}</div>

а эти строчки HTML разве не порождают watcher-ов?

Посмотрите на ваш пример jsfiddle.net/olegdunkan/DZ3At/4/ я его немного модифицировал в функцию logger добавил
фиктивные изменения переменных main.nonObservableVar.one и main.nonObservableVar.two, и естественно они изменились, а значит
watcher-ы присутствуют.
Скажите пожалуйста, что вы имели в виду когда писали что их нет, где их нет?

[KhodeN]

Ну одно из преимуществ, то что тут нет angular watcher’ов.

Как это нет? При изменении значения в main.nonObservableVar.one оно измениться и во вьюшке. main — обычное поле в $scope, отслеживается как любое другое. Я не прав?

[KhodeN]

Сорри, выше подобный вопрос… Лучше на него ответить