что такое модуль angular
Основы AngularJS
Модули в AngularJS
Основной формой организации приложений в AngularJS являются модули. Модуль представляет хранилище различной информации: директив, фильтров, контроллеров и т.д. При этом одно приложение может иметь несколько модулей. Например, разные модули могут представлять какую-либо специфическую функциональность.
Модули позволяют ассоциировать определенный участок html-страницы с приложением AngularJS. Модули также позволяют организовать и структурировать различные компоненты приложения AngularJS. Кроме того, модульность архитектуры приложения повышает тестируемость, и мы можем использовать различные части-модули приложения в других приложениях.
Название модуля. Согласно соглашениям о наименовании модуль должен иметь суффикс App
Набор других модулей в виде строкового массива, от которых данный модуль зависит
Конфигурационные настройки модуля
Здесь создается модуль myApp. Вместо набора модулей, передаваемых вторым параметром, мы можем отставить пустым массивом. В то же время было бы ошибкой вообще убрать этот параметр. Так как выражение var myApp = angular.module(‘myApp’); будет представлять попытку получить модуль myApp в одноименную переменную, а не создать его.
Чтобы ассоциировать модуль с определенным куском html-страницы, нужно использовать директиву ng-app:
Используя модуль, мы можем определить ряд компонентов, таких как контроллеры, сервисы и т.д., которые затем применяются в приложении. Для этого объект Module имеет ряд методов, наиболее используемые из них:
config(callback) : регистрирует функцию callback, которая используется для его конфигурации в процессе загрузки
constant(key, value) : определяет сервис, который возвращает константное значение value
controller(name, constructor) : создает контроллер
directive(name, factory) : создает директиву, которая расширяет стандартную разметку html
factory(name, provider) : создает службу
filter(name, factory) : создает фильтр
provider(name, type) : создает сервис
service(name, constructor) : создает сервис
Введение в модули Angular — корневой модуль (Root Module)
Прим. перев.: для понимания данной статьи необходимо обладать начальными знаниями Angular: что такое компоненты, как создать простейшее SPA приложение и т.д. Если Вы не знакомы с данной темой, то рекомендую для начала ознакомиться с примером создания SPA приложения из оф. документации.
Вступление
@NgModule — декоратор, добавленный в Angular 2. Из официальной документации следует, что @NgModule определяет класс, как модуль Angular. Модули Angular помогают разбивать приложение на части (модули), которые взаимодействуют между собой и представляют в конечном итоге целостное приложение. Иными словами, модуль — это упаковка или инкапсуляция части функционала приложения. Модули можно проектировать с учетом многократного использования, т.е. не зависящие от конкретной реализации приложения.
Обратите внимание, что если вы хотите реализовать lazy load в Вашем приложении, то необходимо использовать концепцию Angular Modules при проектировании приложения.
Корневой модуль (Root Module)
В качестве аргумента в декораторе @NgModule используется JavaScript объект.
Как происходит загрузка компонента в DOM?
Каким образом AppModule добавляет компонент в DOM?
AppModule выступает в роли связующего между данными, их представлением и браузером.
Компоновка приложения
В примере выше мы используем динамическую компиляцию (JIT — Just In Time). Однако в Angular можно реализовать AOT-компиляцию (Ahead of Time), однако это обширная тема и будет рассмотрена в другой статье.
Декларирование (объявление)
В наших приложения мы создаем свои компоненты, директивы и пайпы. Мы можем сообщить нашему приложению о том, какой функционал мы хотим добавить (компоненты, директивы и пайпы) путем перечисления их в свойстве declarations объекта, который является аргументом для декоратора @NgModule :
После объявления компонентов мы можем использовать их внутри других компонентов через их селектор, который указывается в описании компонента.
Импортирование и вложенные модули
Провайдеры
Часто в наших приложениях есть сервисы, которые мы хотим использовать в нескольких (или во всех) компонентах. Как предоставить всем компонентам доступ к сервису? Использовать Angular Modules.
Когда мы представили эти сервисы в корневом модуле AppModule они доступны в компонентах приложения:
Опишем, как это работает. Мы добавили в конструктор нашего компонента создание объекта провайдера, выглядит это примерно так:
Заключение
Провайдеры, на мой взгляд, одна из самых интересных и сложных концепций модульной системы Angular. Основное правило использования провайдеров (сервисов) — создать экземпляр сервиса в корневом модуле и передавать по запросу этот экземпляр в другие части (компоненты) приложения.
— Telegram русскоязычного Angular сообщества.
Использование модуля Angular NgModules для многоразового кода и многое другое
Дата публикации: 2018-06-04
От автора: в Angular модуль NgModules — основная концепция, которая является частью каждого приложения и помогает связать некоторые важные детали для компилятора и runtime. Они особенно полезны для организации кода в функциях, ленивых роутов загрузки и создания многоразовых библиотек.
В этом руководстве мы рассмотрим основные виды использования NgModules с некоторыми примерами, чтобы показать вам, как их использовать в ваших проектах с Angular! В этом руководстве предполагается, что у вас есть знание Angular.
Модули JavaScript не являются NgModules
Давайте сначала проясним, что такое модули JavaScript (иногда называемые модулями ES6). Это языковая конструкция, которая упрощает организацию вашего кода.
Когда вы создаете Angular приложение с TypeScript, каждое использование import или export в исходном коде считается модулем JavaScript. TypeScript способен обрабатывать загрузку модуля для вас.
Бесплатный курс «Laravel + Angular. Быстрый старт»
Изучите курс и узнайте, как создать веб-приложение с нуля на Angular и Laravel
Примечание. Чтобы все было ясно в этой статье, я всегда буду ссылаться на модули JavaScript и NgModules по их полному имени.
Основной NgModule, AppModule
Давайте начнем с изучения базового NgModule, который существует в каждом приложении Angular, AppModule (который генерируется по умолчанию в любом новом Angular приложении). Это похоже на:
Angular использует декораторы для определения метаданных, которые необходимо знать во время компиляции. Чтобы определить NgModue, вы просто добавляете декоратор @NgModule() над классом. Класс не всегда может быть пустым, но часто это так. Однако вам нужно будет определить объект с некоторыми свойствами для NgModule, чтобы что-либо сделать.
Когда приложение загружается, ему должен быть предоставлен NgModule для создания экземпляра. Если вы посмотрите в основной файл приложения (также обычно называемый main.ts), вы увидите platformBrowserDynamic().bootstrapModule(AppModule), то есть как приложение регистрирует и запускает AppModule (который можно назвать как угодно, но почти всегда называют так).
Свойства NgModule
На странице документации API NgModule перечислены свойства, которые вы можете передать при определении NgModule, но мы также рассмотрим их здесь. Они все необязательны, но вам нужно будет определить значения, по крайней мере, для одного из них, чтобы NgModule мог что-то сделать.
Свойства NgModule
На странице документации API NgModule перечислены свойства, которые вы можете передать при определении NgModule, но мы также рассмотрим их здесь. Они все необязательны, но вам нужно будет определить значения, по крайней мере, для одного из них, чтобы NgModule мог что-то сделать.
providers
providers — это массив, содержащий список любых провайдеров (инъекционных сервисов), доступных для этого NgModule. У провайдеров есть область видимости, и если они перечислены в ленивом загруженном NgModule, они недоступны вне этого NgModule.
declarations
Массив declarations должен содержать список любых директив, компонентов или пайпов, которые определяет этот NgModule. Это позволяет компилятору найти эти элементы и обеспечить их правильное соединение. Если это корневой NgModule, тогда объявления доступны для всех NgModules. В противном случае они видны только одному и тому же NgModule.
imports
Если ваш NgModule зависит от любых других объектов от другого NgModule, вам придется добавить его в массив imports. Это гарантирует, что система вставки зависимостей и компилятор знают об импортированных элементах.
exports
Используя массив exports, вы можете определить, какие директивы, компоненты и пайпы доступны для любого NgModule, который импортирует этот NgModule. Например, в библиотеке пользовательского интерфейса вы экспортируете все компоненты, составляющие библиотеку.
entryComponents
bootstrap
schemas
Схемы — это способ определить, как Angular компилирует шаблоны, и выкинет ли он ошибку, когда найдет элементы, которые не являются стандартными HTML или известными компонентами. По умолчанию Angular выдает ошибку, когда находит элемент в шаблоне, который он не знает, но вы можете изменить это поведение, установив схему либо NO_ERRORS_SCHEMA (чтобы разрешить все элементы и свойства), либо CUSTOM_ELEMENTS_SCHEMA (чтобы разрешить любые элементы или свойства с – в их имени).
Это свойство позволяет вам предоставить NgModule уникальный идентификатор, который вы можете использовать для получения заводской ссылки модуля. Редко используется.
Примеры NgModule
Чтобы проиллюстрировать, как NgModule используется с Angular, давайте рассмотрим набор примеров, которые показывают, как легко обращаться с различными вариантами использования.
Особенности NgModules
Самый простой пример использования NgModules, помимо AppModule — для Feature NgModules (обычно называемых функциональными модулями, но они не позволяют согласовать термины). Они помогают разделить отдельные части вашего приложения и настоятельно рекомендуются. В большинстве случаев они такие же, как и основной App NgModule. Давайте рассмотрим базовую функцию NgModule:
Этот простой Feature NgModule определяет четыре компонента, один провадйер и импортирует два модуля, которые требуются компонентами и сервисом. Вместе они включают необходимые фрагменты для раздела форумов приложения.
Как мы узнали ранее, элементы в declarations фактически не доступны для использования в других NgModules, поскольку они являются частными для этого NgModule. Чтобы исправить это, вы можете экспортировать те декларации, которые хотите использовать в других NgModules, например, в этом фрагменте, где он экспортирует только ForumsComponent. Теперь в любых других функциях NgModules вы можете поместить forums (или что бы то ни было селектором для компонента) для отображения ForumsComponent в шаблоне.
Другим ключевым отличием является то, что ForumsModule импортирует CommonModule вместо BrowserModule. Модуль BrowserModule должен быть импортирован только в корневой NgModule, но CommonModule содержит основные Angular директивы и пайпы (такие как NgFor и пайп Date). Если ваш Feature NgModule не использует ни одну из этих функций, на самом деле ему не нужен CommonModule.
Теперь, когда вы хотите использовать ForumsModule в своем проекте, вам нужно импортировать его в свой AppModule как вы видите здесь:
Архитектура приложения Angular. Используем NgModules
Прим. перев.: для понимания данной статьи необходимо обладать начальными знаниями Angular: что такое компоненты, как создать простейшее SPA приложение и т.д. Если Вы не знакомы с данной темой, то рекомендую для начала ознакомиться с примером создания SPA приложения из оф. документации.
Об NgModules можно прочитать здесь.
Один год назад я уже публиковал статью об NgModules, где рассматриваются технические тонкости, когда импортировать модули, пространство имен и т.д. Рекомендуется для ознакомления (прим. перев.: статья по содержанию аналогична той, на которую я ссылаюсь вначале).
Недавно я принял вызов, который мне бросил Angular. До сих пор я использовал подход, предлагаемый официальной документацией Angular. Но дойдя до большого проекта стали проявляться недостатки.
Я начал детально изучать мануал по NgModules, который разросся аж до 12 страниц подробного описания с FAQ. Но после внимательного прочтения вопросов возникло больше, чем ответов. Например, где лучше реализовать сервис? Внятного ответа на этот вопрос получить не получилось. Более того, некоторые решения противоречат друг другу в контексте мануала.
После переваривания всего раздела про NgModules я решил реализовать свое решение по архитектуре Angular приложений, основанное на следующем:
Angular Modules
Что такое модули Angular?
На самом деле, главная цель модуля — группирование компонентов и/или сервисов, связанных друг с другом. И, в общем-то, больше ничего. Для примера, представим блок новостей на главной странице. Если грубо, то визуальная часть — это компонент, а механизм получения данных из базы данных — это сервис.
Для тех, кто знаком с Java, то модули Angular это пакеты (packages), а в C#/PHP — пространство имен.
Остается только один вопрос — как правильно группировать функционал приложения?
Типы модулей Angular
Как только вы создали стартовое приложение через ng new projectname
то, как минимум, вы создали модуль страницы. В данном случае одной — главной.
По мере того, как Ваше приложение будет расти, вы будете создавать новые модули для страниц, сервисов, компонентов и группировать их между собой. Если, конечно, вы хотите получить обслуживаемое и масштабируемое приложение, а не слить весь функционал в одном файле.
Модули страниц
Модули страниц обладают маршрутизацией и предназначены для того, чтобы логически разделить области вашего приложения. Модули страниц загружаются один раз в главном модуле (который обычно называется AppModule ) или через lazy load.
Для примера, на странице авторизации, выхода и регистрации нужен модуль AccountLogin ; HeroesModule для страницы списка героев, страницы героя и т.д. (прим. перев.: здесь имеется ввиду учебный проект, который описывается в официальной документации).
Модули страниц могут содержать в себе:
Общедоступные сервисы для страниц
Для отображения данных на странице, сначала нужно эти данные откуда-то взять. Для этого и нужны сервисы
Впоследствии, некоторым страницам нужны будут схожие данные, а значит — сервисы одного типа. В таком случае необходимо сделать один сервис и общедоступным во всем приложении, а не в конкретном модуле.
Но для лучшей практики лучше спроектировать модуль так, чтобы конкретная страница требовала определенного типа данных, определенного сервиса. В таком случае нужно инкапсулировать данный сервис и ограничить доступ к нему внутри одного модуля, а не всего приложения.
Прим. перевод.
При такой архитектуре Ваше приложение будет проще обслуживать, т.к. вся логика приложения будет разбита на блоки, отвечающая за выполнение определенного функционала. Если все слить в один сервис и сделать его доступным во всем приложении, то будут проблемы с расширением функционала, приведет к противоречию принципам разделения интерфейсов, единой ответственности и прочему SOLID. Впрочем, как проектировать архитектуру Вашего приложения решать Вам.
Модули-страницы: маршрутизация
Компонент страницы отвечает за представление информации из базы данных, которая извлекается сервисом.
Вы можете отображать данные непосредственно в компоненте, но Вы не обязаны этого делать. Вы можете передать данные в виде переменной в другой компонент
Каждый компонент имеет свой маршрут.
Компоненты для визуализации данных
Компоненты для представления данных извлекают информацию при помощи декоратора @Input и отображают в своем шаблоне
Это MVx?
Кто знаком с паттерном модель-контроллер-представление задастся вопросом — это оно самое? Если следовать теории, то нет. Однако, если Вам проще представить архитектуру Angular при помощи MVx, то:
services сравнимы с Models,
presentation components похожи на View,
page components будут Controllers \ Presenters \ ViewModels (выберете то, что вы используете).
Несмотря на то, что это не совсем MVx (или совсем не MVx), цели в данном подходе одинаковы — разделение ответственности в решении задач. Почему это важно? Вот почему:
Суммируя
Пример модуля страницы
где сервис инкапсулирован в данном модуле.
Модули глобальных сервисов
Модули глобальных сервисов предоставляют доступ к своему сервису в любом месте Вашего приложения. Так как такие сервисы имеют глобальную область видимости, эти модули загружаются только один раз в корневой модуль ( AppModule ) и доступны везде, в т.ч. при реализации lazy load.
Юзабилити
Если Вы будете осторожный в проектировнии модуля для глобального сервиса, сделаете его без визуальной части, разобьете логику сервиса на отдельные модули и будете проектировать на уровне интерфейса, а не реализации конкретного приложения (т.е. не будете внедрять зависимости конкретного приложения), то такие модули могут быть использованы в других проектах.
Следует отметить, что если Вы хотите сделать модуль доступным в других проектах (т.е. из вне), необходимо создать для него точку входа, куда вы экспортируете NgModule, интерфейс и, возможно, токены для внедрения.
Должен ли я делать CoreModule
Суммарно
Пример глобального модуля для сервиса
UI компоненты и как получать данные
Вы не должны целиком полагаться на сервис. Почему? Потому что сервисы имеют свою специфику в зависимости от предложения. Например, может поменяться URL у API. Представление данных — дело компонентов внутри страниц модулей. UI компоненты получают данные, предоставленные кем-то, но не ими.
Открытые (public) и скрытые (private) компоненты
Для того, чтобы сделать компонент доступным (public) нужно экспортировать его в модуле. Однако, импортировать все не нужно. Вложенные компоненты должны\могут оставаться скрытыми (private), если в них нет необходимости в другом месте приложения.
Директивы и пайпы
Если говорить о модулях для директив и пайпов, то аналогично с UI компонентами. По необходимости экспортируем в модуле и используем там, где нам вздумается.
Скрытые (private) сервисы
Для работы с данными исключительно внутри UI компонента можно реализовать сервис только внутри компонента, а не NgModule и сделать его закрытым для всего, кроме его компонента. В таком случае это будет выглядеть так
Общедоступные (public) сервисы
Представим ситуацию, когда Вы хотите открыть доступ к сервису, который реализовали в UI компоненте. Такое следует максимально избегать, но реализовать возможно.
Открываем доступ к сервису в NgModule и получаем проблему многократной загрузки модуля, а с ним и сервиса, т.к. в модуле мы реализуем компонент.
Для решения данной проблемы необходимо реализовать модуль таким образом
Кстати, так реализовано (по крайней мере было) в Angular CDK.
Юзабельность
Для использования UI компонентов в виде модулей, необходимо экспортировать компоненты\пайпы\директивы и тд, открыть им доступ создав точку доступа
Нужно ли делать SharedModule?
Нужно ли сливать все весь пользовательский интерфейс (UI компоненты) в SharedModule Определенно нет. Хотя документация предлагает данное решение, но каждый модуль, реализованный в SharedModule будет реализован на уровне проекта, на не интерфейса.
Нет проблем в ипортировании зависимостей при создании проекта, особенно при помощи автоматизации этого процесса в VS Code (или других IDE).
Однако, куда лучшим тоном будет создать раздельные модули для каждой сущности пользовательского интерфейса и сложить их в папку /ui, например.
Суммарно
Что в итоге?
Если Вы будете проектировать Ваше приложение с учетом описанного выше, то:
Вы будете иметь хорошо структурированную архитектуру, будь то в малых или больших приложениях, с или без lazy load.
Вы можете упаковать глобальные модули или UI компоненты в библиотеки и использовать их в других проектах.
Вы будете тестировать приложения без агонии.
Пример структуры проекта
Если у Вас есть комментарии по данной архитектуре, то, пожалуйста, оставьте свои коментарии.
— Telegram русскоязычного Angular сообщества.
Что такое Angular. Начало работы с фреймворком¶
Angular представляет фреймворк от компании Google для создания клиентских приложений. Прежде всего он нацелен на разработку SPA-решений (Single Page Application), то есть одностраничных приложений. В этом плане Angular является наследником другого фреймворка AngularJS. В то же время Angular это не новая версия AngularJS, а принципиально новый фреймворк.
Angular предоставляет такую функциональность, как двустороннее связывание, позволяющее динамически изменять данные в одном месте интерфейса при изменении данных модели в другом, шаблоны, маршрутизация и так далее.
Одной из ключевых особенностей Angular является то, что он использует в качестве языка программирования TypeScript.
Но мы не ограничены языком TypeScript. При желании можем писать приложения на Angular с помощью таких языков как Dart или JavaScript. Однако TypeScript все таки является основным языком для Angular.
Официальный репозиторий фреймворка на гитхабе: https://github.com/angular/angular. Там вы можете найти сами исходные файлы, а также некоторую дополнительную информацию.
Начало работы c Angular¶
Для работы с Angular необходимо установить сервер Node.js и пакетный менеджер npm, если они отсутствуют на рабочей машине. Для установки можно использовать программу установки node.js. Вместе с сервером она также установит и npm. При этом особого какого-то знания для работы с NodeJS и npm не требуется.
Данный файл устанавливает пакеты и зависимости, которые будут использоваться проектом. В секции dependencies в основном определяются пакеты angular, которые необходимы приложению для работы. В секции devDependencies прописаны только те пакеты, которые будут использоваться для разработки. В частности, это пакеты для работы с языком typescript (так как мы будем писать код приложения на языке TypeScript), а также пакеты, необходимые для сборки приложения в один файл с помощью сборщика webpack.
Затем откроем командную строку (терминал) и перейдем в ней к папке проекта с помощью команды cd :
Создание компонента Angular¶
Компоненты представляют основные строительные блоки приложения Angular. Каждое приложение Angular имеет как минимум один компонент. Поэтому создадим в папке src/app новый файл, который назовем app.component.ts и в котором определим следующий код компонента:
Создание модуля приложения¶
Приложение Angular состоит из модулей. Модульная структура позволяет легко подгружать и задействовать только те модули, которые непосредственно необходимы. И каждое приложение имеет как минимум один корневой модуль. Поэтому создадим в папке src/app новый файл, который назовем app.module.ts со следующим содержимым:
Запуск приложения¶
Теперь нам надо указать Angular, как запускать наше приложение. Для этого создадим в папке src (на уровень выше, чем расположены файлы app.component.ts и app.module.ts ) файл main.ts со следующим содержимым:
Также в папке src определим еще один файл, который назовем polyfills.ts со следующим кодом:
Данный файл определяет полифилы — инструменты, которые необходимы для поддержки приложения на Angular старыми браузерами.
Создание главной страницы¶
Далее определим в папке src главную страницу index.html приложения:
Определение конфигурации¶
Поскольку для определения кода приложения применяется язык TypeScript, поэтому также создадим в корневой папке проекта новый файл tsconfig.json :
Angular.json¶
Проект определяет следующие опции:
Параметр options задает параметры построения файлов. Для команды » build » здесь определены следующие опции:
Последняя опция defaultProject указывает на проект по умолчанию. В данном случае это наш единственный проект.
В итоге у нас получится следующая структура проекта:
Запуск проекта¶
И теперь, когда все готово, мы можем запустить проект. Для этого в командной строке (терминале) перейдем к папке проекта с помощью команды cd и затем выполним команду ng serve:
Введем в текстовое поле какое-нибудь имя, и оно тут же отобразится в заголовке.
Важно отметить, что пока приложение запущено, мы можем поменять код, и Angular CLI почти моментально перекомпилирует и перезапустит приложение.