Как лучше организовать приложение на Angular?

Question

[coderisimo]

Написал приложение из 5-ти отдельных страниц/представлений/контроллеров. 5-расчетов.
Позже возникла необходимость перенести все на одну страницу (вместо 5, как было изначально). Думаю, как бы поэлегантнее все организовать.
Разумеется, все можно свалить в одну кучу (в один контроллер), вместо $scope.vatiable переменные/методы каждого из 5 контроллеров положить в свою область видимости типа $scope.controller1.variable. (и так для всех 5 контроллеров) таким образом застрахуюсь от пересечения имен и буду иметь доступ к общему представлению из каждого куска перенесенного кода. Может есть способы получше?
С ангуляром на "Вы", так что сложные вещи пробовать нет времени, но может есть простые и при этом удобные?
У меня день на "все про все" . Расчеты сложные, если что-то сломается, будет очень трудно разобраться.

Спасибо

Answer 1

[Kostya Gorozhanov]

вместо того чтобы делать так $scope.controller1.variable. (и так для всех 5 контроллеров), почитайте о ng-controller="SettingsController as settings", так логика будет в разных контроллерах но представление можно сделать одно.

Comments

[coderisimo]

У меня есть два поля. При изменении данных в них должны пересчитываться все 5 расчетов и результаты расчетов должны отображаться в преставлении. Пока мне кажется наиболее реальным путь г...кода.
Да это тупо, но все будет в куче, все понятно и должно работать ))
А все эти "всё биндим к контроллерам" или "все операции с данными через сервисный слой" звучат пугающе и создается ощущение, что "просто" здесь ничего не будет. А "сложно" , увы не успею.

Спасибо за ответ

[Kostya Gorozhanov]

https://toddmotto.com/digging-into-angulars-contro...

[coderisimo]

Спасибо! Буду вникать.

Answer 2

[Владимир Ио]

Все просто - делаете 5 модулей, которые зависимостями выносите в один - главный.
У каждого модуля свой функционал, свои директивы, свои контроллеры.
Если нужна связь между главным контроллером и дочерними через общие объекты - просто объявляете эти объекты в главном, а используете в дочерных(принцип замыкания по сути).
Если нужны общие объекты между директивами, используете изолированный scope у директив, указывая какие именно объекты будут поданы наружу.
Все.

Comments

[coderisimo]

к примеру :

у меня есть модуль:

'use strict';

angular.module('myApp.csodds', ['ngRoute'])

        .config(['$routeProvider', function ($routeProvider) {
                $routeProvider.when('/csodds', {
                    templateUrl: 'csodds/csodds.html',
                    controller: 'View1Ctrl'
                });
            }])

        .controller('View1Ctrl', ['$scope',  function ($scope) {

                $scope.Poisson = window.PoissonDistrib;

                $scope.home_input =0;
                $scope.away_input=0;
 //etc

я создал в том же приложении еще один :

'use strict';

angular.module('myApp.calculation', ['ngRoute'])

        .config(['$routeProvider', function ($routeProvider) {
                $routeProvider.when('/calculation', {
                    templateUrl: 'calculation/calculation.html',
                    controller: 'Calc1Ctrl'
                });
            }])

        .controller('Calc1Ctrl', ['$scope', function ($scope) {

            }]);

как мне во втором использовать первый? например, получить доступ к $scope.home_input ?

[Николай]

coderisimo: сделать сервис, в котором будет храниться ваш home_input. Заинжектить этот сервис в оба модуля.

[coderisimo]

В каждом модуле у меня по 20-30 полей, которые ранее были связаны со своим представлением.
Соответственно, эти поля тоже могут быть доступны в главном модуле и его представлении через сервис?
Если я сделаю эти поля свойствами одного объекта, могу я просто использовать общий объект?
И все переменные из всех 5 расчетов, которые нужны мне в общем представлении я должен объявить в этом сервисе? Решение уже не выглядит таким уж простым)).
Извините , если вопросы ламерские. Других пока нет. Ясно, что надо для начала как следует 'покурить доки' самого JS , займусь этим обязательно, но сейчас надо решить насущную проблему )

[Владимир Ио]

coderisimo:
"Соответственно, эти поля тоже могут быть доступны в главном модуле и его представлении через сервис?"
Ну не поля, а их модели. Можно шарить их через сервис.

Если я сделаю эти поля свойствами одного объекта, могу я просто использовать общий объект?
Да, но он должен быть объявлен в самом верхнем уровне из использующих его модулей.

"И все переменные из всех 5 расчетов, которые нужны мне в общем представлении я должен объявить в этом сервисе?"
Вы путаете. Если шарите через объект - объявляете на верхнем уровне объект. Если через сервис - объявляете в сервисе и получаете из него. Это разные подходы.

Answer 3

[bromzh]

Добавлю к советам Николай
https://github.com/johnpapa/angular-styleguide
Советую почитать и следовать. Лучше сразу приучиться писать хорошо, чем потом переучиваться.

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

Так что делай 5 директив, потом вставляй их на страницу.

Comments

[coderisimo]

Спасибо, обязательно почитаю!
Насчет 5 директив в конце не совсем понял.
"Директива дает возможность создавать новые HTML теги и атрибуты" . У меня в каждом из 5 модулей куча расчетов по итогам которых строится по связанных несколько таблиц. Как в этом случае можно использовать директивы?

вот он, этот монстр, которого нужно свалить на одну страничку flysite.byethost31.com/calc/app/#/csodds :)

Answer 4

[Николай]

1. Все операции с данными через сервисный слой. Т.е. никаких изменений данных в директивах, только через вызовы соответствующих данным сервисов.
2. Никакой логики в контроллерах, кроме подготовки данных (например проброс resolve).
3. UI-router вместо стандартного роутера.
4. Операции с DOM только в link функции директивы и только в случае каких-то сложных вещей (в основном анимации).
4. Логика директивы в контроллере, а не в link функции.
5. Никаких обращений к родительским scope из текущего.
6. Использовать scope по минимуму(всё биндим к контроллерам)

Comments

[coderisimo]

Думаю, через недельку чтения мануалов я вас пойму. Спасибо!

[Владимир Ио]

Насчет пункта 2. Я ошибаюсь, или это было в ангуляре около версии 1-1.2. Сам кажется видел, сейчас же они пишут уже иначе. То есть логику дома не пихать в контроллер, а бизнес логику то как раз в нем рекомендуется.

Do not use controllers to:

Manipulate DOM — Controllers should contain only business logic. Putting any presentation logic into Controllers significantly affects its testability. Angular has databinding for most cases and directives to encapsulate manual DOM manipulation.

[Николай]

Владимир Ионов: имеются ввиду контроллеры, которые биндятся к вьюшкам. В них не должно быть логики.

[Владимир Ио]

Николай: Либо я чего-то не знаю, либо вы не так выразились:
1. Не вижу ни одного упоминания использования контроллеров без view https://docs.angularjs.org/guide/controller.
2. Смотрим раздел Using Controllers Correctly, первое же предложение: "In general, a Controller shouldn't try to do too much. It should contain only the business logic needed for a single view.". То есть как раз наоборот от того, что вы сказали - много они делать не должны, но вся бизнес логика конкретной вьюшки - в них.

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

[Николай]

Владимир Ионов: внутри директив. Каждая вьюшка должна состоять из набора директив, контроллер вьюшки лишь передает необходимые данные этим директивам ( например данные из resolve'ов). Дальше вся логика происходит на уровне директив.

[Владимир Ио]

Николай: Все, понял какие контроллеры вы имели ввиду. Назрела идея для интересного вопроса. Спасибо за дискуссию.