AngularJS: структурування веб-програми за допомогою декількох ng-додатків

У блогосфері є низка статей на тему керівних принципів щодо структурування додатків AngularJS, таких як ці (та інші):

• http://www.johnpapa.net/angular-app-structuring-guidelines/
• http://codingsmackdown.tv/blog/2013/04/19/angularjs-modules-for-great-justice/
• http://danorlando.com/angularjs-architecture-understanding-modules/
• http://henriquat.re/modularizing-angularjs/modularizing-angular-applications/modularizing-angular-applications.html

Однак один із сценаріїв, на які я ще не зіткнувся з рекомендаціями та найкращими практиками, - це той випадок, коли у вас є велика веб-програма, що містить декілька додатків «міні-спа», а всі програми для міні-спа мають певну кількість коду.

Я не маю на увазі випадок спроби мати кілька ng-appоголошень на одній сторінці; швидше, я маю на увазі різні розділи великого сайту, які мають свою унікальну ng-appдекларацію.

Як пише Скотт Аллен у своєму блозі OdeToCode :

Один із сценаріїв, який я не дуже добре знайшов, - це сценарій, коли в одній великій веб-програмі існує кілька додатків і потрібен деякий спільний код для клієнта.

Чи є які-небудь рекомендовані підходи, які можна застосувати, підводні камені, яких слід уникати, або хороші зразкові структури цього сценарію, на які можна вказати?

Оновлення - 10.10.2015
Один проект із цікавою стратегією організації - MEAN.JS та папка з його модулями.
https://github.com/meanjs/mean
https://github.com/meanjs/mean/tree/master/modules

Ще один приклад з прикладу SPA ASP.NET Music Store SPA. https://github.com/aspnet/MusicStore https://github.com/aspnet/MusicStore/tree/master/src/MusicStore.Spa/ng-apps

Ось дизайн, з яким я працюю. Я вважаю це корисним для двох великих проектів, які я створив, і досі не потрапив на жодні дорожні блоки.

Структура папок

your-project/
  apps/
    global.html
    app1/
      index.html
      app1.module.js
      app1.js
      parts/
        foo.js
        foo.html
        ...
    app2/
  libs
    lib1/
      lib1.module.js
      parts/
        directive1.js
        directive1.html
    lib2/
  third-party/

• Налаштуйте веб-рамку вашого сервера, щоб дізнатись, apps/app1/index.htmlколи /app1надходить запит . Використовуйте дружні URL-адреси (наприклад, the-first-application/замість цього app1/і, якщо потрібно, картографуйте їх за допомогою серверної технології.
• Ваша серверна технологія повинна включати global.htmlв себе, index.htmlоскільки вона містить постачальника включає (див. Нижче).
• Включіть активи, необхідні відповідному додатку, до index.html(див. Нижче).
• Помістіть ng-appі корінь <div ui-view></div>у index.html.
• Кожен додаток і ліб - це окремий кутовий модуль.
• Кожна програма отримує <app-name>.module.jsфайл, що містить визначення кутового модуля та список залежностей.
• Кожен додаток отримує <app-name>.jsфайл, що містить блоки конфігурації та запуску модулів та конфігурацію маршрутизації як частину цього.
• Кожна програма отримує partsпапку, яка містить контролери, погляди, служби та директиви програм у структурі, яка має сенс для конкретного додатка . Я не вважаю підпапок подобається controllers/, і views/т.д. корисно, тому що вони не масштабуються, але YMMV.
• Ваги відповідають тій же структурі, що і програми, але залишають речі, які їм не потрібні (очевидно).

Почніть із служб та директив у додатку, де вони використовуються. Як тільки вам знадобиться щось і в іншому додатку, перейміть його в бібліотеку. Постарайтеся створити функціонально послідовні бібліотеки, а не лише всі директиви або бібліотеки всіх служб.

Активи

Я мінімізую як JS, так і CSS-файли для створення версій, але працюю з незміненими файлами під час розробки. Ось установка, яка підтримує це:

• Управління постачальником включає глобально в global.html. Таким чином, важкі речі можна завантажувати з кешу під час навігації між SPA. Переконайтесь, що кешування працює належним чином.
• Активи на SPA визначені в index.html. Сюди слід включати лише файли, що стосуються додатків, а також використовувані бібліотеки.

Структура папок вище дозволяє легко знайти потрібні файли для кроків побудови мінімізації.

Програми для однієї сторінки (SPA) насправді не призначені для використання так, як ви пропонуєте із дійсно великим додатком та декількома міні-SPA-кодами в межах основного. Найбільшою проблемою буде час завантаження сторінки, оскільки все потрібно завантажувати вперед.

Один із способів вирішити це - використання навігаційної сторінки, яка переведе вас до окремих SPA-систем. Навігаційна сторінка буде досить легкою, і тоді ви будете завантажувати лише один SPA за раз, залежно від обраного. Ви можете надати рядок посилань з навігаційними посиланнями в кожному з ваших SPA-послуг, щоб користувачі не завжди повинні повертатися на сторінку навігації, коли їм потрібно перейти в іншу область.

Використання цього підходу може створити певні труднощі з постійною інформацією через SPA. Але ми говоримо про те, що СПА не мали наміру робити. Існують деякі рамки, які допоможуть зберегти дані на стороні клієнта. Бриз - це перше, що спадає на думку, але є й інші.

Щодо макета - кілька питань програмістів стосуються великого макета проекту, залежно від ваших потреб. Я натрапив на цю та цю . Немає нічого магічного в SPA-режимах, який би впливав на макет вашої програми, крім того, про що вже відповіли в цих питаннях.

Однак, існують різні підходи, які найкраще підходять для різних проектів. Я рекомендую дотримуватися основної компоновки, передбаченої проектом кутового насіння. Створіть окремі папки з наданих для своїх спеціальних пакетів та вихідного коду. А у своїй вихідній папці використовуйте макет проекту, який має сенс для ваших потреб.

Якщо вашій програмі потрібно кілька оголошень ng-додатків на одній сторінці, вам потрібно вручну завантажувати модуль AngularJS, вводячи ім'я модуля, як показано нижче:

angular.element(document).ready(function() {
  angular.bootstrap(document, ['TodoApp']);
});

Цей викрадник детально розглядає, як ми могли вручну завантажувати AngularJS.