Как использовать одну и ту же кодовую базу для нескольких угловых проектов

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

Как здесь : https://github.com/nuxeo/nuxeo-drive/blob/master/nuxeo-drive-client/nxdrive/data/ui5/js/ndrive-settings.js

Спасибо за ответ @FrailWords.

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

Список стратегий, которым следует следовать в этом предложении:

1.  Switch to feature based directory structure. 
2.  Create an angular module for each feature.
3.  Separate common code from instance specific code.
4.  Merge duplicate code.
5.  Remove unused code and outdated libraries.
6.  Re-organize codebase.
7.  Make common code as configurable.
8.  Use same configurable common code for all 5 instances.
9.  Use inheritance or similar mechanisms for extended functionality.
10. Identify & Move functions (methods) from instance specific code to common code.
11. Follow naming conventions.
12. Manage future requirements.
13. Use build tools like gulp or grunt and testing frameworks like jasmine.
14. Application specific look & feel.

Как реализовать эти стратегии:

Ниже мы рассмотрим решения / подходы для каждой стратегии.

1. Переключиться на структура каталогов на основе функций.

Текущая структура каталогов:

Она основана на угловой слоев/типов. То есть мы поместили все контроллеры в одну папку, все сервисы в другую и т.д. Это хорошие небольшие приложения.

Пример:

Предлагаемая структура каталогов:

/resources
--/ui_core                                                      ui-core or common code
-----/app
-------------------core_module.js                   inject all modules from /ui_core/modules into this 
-------------------config_module.js                declare constants and inject into core_module 
-----/shared_services                                   part of core_module 
-----/shared_directives                                part of core_module – place directive’s js+html here
-----/shared_filters                                       part of core_module 
-----/shared_views                    
-----/shared_interceptors                 
-----/shared_content
------------/images
------------/icons
------------/signatures
-----/modules
 ------------/common_feature1
-------------------common_feature1_module.js
-------------------common_feature1Controller.js
-------------------common_feature1Service.js
-------------------common_feature1Directive.js
-------------------common_feature1Filter.js                                  if any
-------------------common_feature1_view.html
-------------------common_feature1_test.js
-------------------common_feature1.css                                         if any
------------/common_feature2
-------------------common_feature2_module.js
-------------------common_feature2Controller.js
-------------------common_feature2Service.js
-------------------common_feature2Directive.js
-------------------common_feature2Filter.js
-------------------common_feature2_view.html
-------------------common_feature2_test.js
-------------------common_feature2.css
-----/vendor                                                                      downloaded vendor libraries
------------/js
-------------------/angular
-------------------/kendo
-------------------/jquery
------------/css
-------------------/kendo
-------------------/bootstrap
------------/images
-------------------/kendo
-------------------/bootstrap
--/ui_equity                                    application specific code – for example: equity
-----/app                 
-------------------equity_module.js  inject ui_core module/any module as required.
-----/shared_services                     part of equity_module 
-----/shared_directives                  part of equity_module  – place directive’s js+html here
-----/shared_filters                         part of equity_module 
-----/shared_views
-----/interceptors
-----/content
------------/images
------------/icons
------------/signatures
-----/modules
 ------------/feature1
-------------------feature1_module.js
-------------------feature1Controller.js
-------------------feature1Service.js
-------------------feature1Directive.js
-------------------feature1Filter.js
-------------------feature1_view.html
-------------------feature1_test.js
-------------------feature1.css
------------/feature2
-------------------feature2_module.js
-------------------feature2Controller.js
-------------------feature2Service.js
-------------------feature2Directive.js
-------------------feature2Filter.js
-------------------feature2_view.html
-------------------feature2_test.js
-------------------feature2.css
--/minified
-----/ui_core
-----/ui_equity 
/webapp
-----/WEB-INF
------------/jsp
-------------------index.jsp
-------------------jsincludes.jsp
-------------------cssincludes.jsp
-------------------imageviewer.jsp
-------------------unauthorized.jsp

2. Создайте угловой модуль для каждого объекта.

Чтобы сделать наши приложения модульный, создайте угловой модуль для каждой основной функции / функциональности нашего приложения. Мы можем вводить эти модули везде, где это необходимо.

Преимущества:

1. Простота повторного использования модульных приложений.

2. Улучшенная читабельность:нет необходимости вводить отдельные компоненты в другие компоненты, достаточно ввести модуль.

3. Отделите общий код от кода конкретного экземпляра.

Список предметов который может быть частью ui_core (common code)

a.  Most of the directives
b.  Filters
c.  Utilities , such as arrayUtilities.js, dateUtilities.js, stringUtilities.js
d.  Services
e.  KendoGridServices & relevant controllers.
To make   kendoGrid as part of common code, below changes are required.

For example,
-   Create model outside datasource - Currently schema “model” is hardcoded inside abccontroller.js , instead of this create “kendo model” outside abccontroller.js and pass/inject to abccontroller.js

-   Currently “columns” are hardcoded inside kendoabcgridservice.js. Instead of this, create “columns array” outside and inject it into kendoabcgridservice.js .

-   Similarly, move out any other instance specific code from kendo grid.

Приведенные ниже стратегии не требуют объяснений, поэтому мы можем перейти к следующей...

    4.  Merge duplicate code.
    5.  Remove unused code and outdated libraries.
    6.  Re-organize codebase.

7. Сделайте общий код настраиваемым.

A. создайте модуль конфигурации внутри общего кода

( /resources/ui_core/app/ config_module.js).

B. объявите константы внутри этого модуля, например APP_NAME = ‘equity’ и все, что потребуется.

C. измените общий код (ui_core), используя APP_NAME постоянный, таким образом, один и тот же блок кода будет вести себя по-разному для разных приложений.

Например,

Вместо $resource(‘/equity/tasks’) используйте $resource(‘/APP_NAME/tasks’)

Примечание: выше - это, например, только цель (на данный момент), изменения в URL-адресах вызовов служб, которые будут завершены после повторного факторинга на стороне сервера/Java.

Пример 2:

If (APP_NAME == ‘equity’){
             //do ‘equity’ specific things
} else if (APP_NAME == ‘commodities’){  
           //do ‘commodities’ specific things
} else {
……………..
}

8. Используйте один и тот же настраиваемый общий код для всех 5 экземпляров.

    As explained earlier

9. Использовать наследование или подобное механизмы для расширенной функциональности.

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

Используя

angular.extend 
Or 
angular.copy

Или аналогичные подходы.

10. Идентификация и перемещение функций (методов) из кода конкретного экземпляра в общий код.

As explained earlier

11. Следовать именования конвенции

Для лучшей ремонтопригодности и согласованности определите и следуйте определенному соглашению об именовании файлов.

Например,

Если имя функциональности - "пользователь", то именование может быть таким, как показано ниже.

/modules
-----/user
----------user_controller.js
----------user_service.js
----------user_directive.js
----------user_view.html
----------user_test.js

Либо следуйте user_controller.JS или user_ctrl .js, но, никогда не делайте и то и другое одновременно.

12. Управление будущими требованиями

Поскольку мы живем в реальном мире , изменения и усовершенствования-это часть жизни. Как только мы реализуем вышеописанное предложение, будет очень легко модифицировать/улучшать функции, не затрагивая другую часть приложения.

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

• где я собираюсь добавить эту функцию, в общем коде или коде конкретного приложения?

Enjoy and Have Fun :-)