Angular компоненты создание, основы работы с приложением, примеры кода


Содержание материала:

Создание компонентов

Компоненты ключевая особенность Angular. Приложение строится из компонентов.

# Создание компонента

В директории app создать папку нового компонента и файл (должен содержать .component в имени), например:
app/server/server.component.ts

Файл должен наследовать класс ServerComponent и содержать декоратор:

@Component() — это декоратор компонента. Он отмечает, что класс является компонентом angular и содержит мета настройки.
В файл app.modules.ts нужно указать новый класс:

@NgModule() — это декоратор модуля. Он может содержать следующие ключи:

  • declarations — компоненты приложения. Сообщает Ангулару какие компоненты принадлежат данному модулю.
  • imports — импортируемые модули. Здесь содержатся модули без которых данный модуль не может работать.
  • providers — сервис провайдеры. Список сервисов, которые будут доступны во всем приложении.
  • bootstrap — корневой компонент, который Ангулар создает и вставляет в index.html главной страницы

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

# Шаблон

Создадим шаблон компонента app/server/server.component.html

Создадим демо данные в шаблоне:

Теперь можно подключить компонент в шаблоне приложения, в файле app.component.html :

# Создание компонента в CLI и вложенные Компоненты

ng generate component #name#

или сокращенный вариант:
ng g c #name#

опции (не создавать файл тестов):
ng g c recipes —spec false

создать компонент в определенной папке:
ng g c recipes/recipe-list

# Пример использования

Запустим команды:
ng g c servers
ng g c server

После выполнения данной команды сгенерируется компонент servers и server.

Теперь в шаблоне приложения app.component.html подключим компонент servers:

А в шаблоне компонента servers app\servers\servers.component.html подключим 2 компонента server :

Компоненты могут быть вложены друг в друга. Это помогает создать удобную структуру проекта:

Internal Server Error

Error 500

This could be due to one of the following reasons:

.htaccess file was misconfigured

Permissions for the file requested on site were misconfigured

PHP or CGI code was misconfigured in the file that is requested on site

Site resources are approaching their maximum limits

Please contact the server administrator webmaster@coderlessons.com and provide the following information:

The time the error occurred

The actions you took prior to and immediately following the error. This will help the administrator better understand what may have caused the error. Please refer to the server error log for more information.

angular-cli Создание компонентов

пример

Чтобы добавить компонент с селектором [prefix]-user-list , запустите:

префикс предотвращает конфликты имен элементов с компонентами в других приложениях и с собственными элементами HTML. Так, например, если префикс app — генерируется компонент будет иметь app-user-list выбора.

  • Чтобы предотвратить использование префикса, добавьте флаг —prefix false или -p false
  • Чтобы предотвратить .spec файлов .spec добавьте —spec false или -sp false flag
  • Чтобы использовать встроенные html-шаблоны вместо внешних шаблонов, добавьте —inline-template или -it флаг
  • Чтобы использовать встроенные стили вместо внешних стилей, добавьте —inline-style или -is flag
  • Чтобы предотвратить создание папок, добавьте —flat или -f

Вы также можете комбинировать перечисленные выше флаги. Например, для создания файла .component.ts без файлов .css , .html , .spec и папки используйте следующую команду.

Все generate component флаги generate component :

Введение в AngularJS и простейший пример приложения

| Среда, 5 июня, 2013

AngularJS является структурированной средой для разработки динамических веб-приложений. C данным фреймворком HTML можно использовать как собственный шаблонный язык и расширять его синтаксис так, чтобы написание приложений становилось как можно проще и лаконичнее. Стандарный набор инструментов среды, позволяет избежать написания в приложении большого объема кода, используя связывание данных и внедрение зависимости. И это все происходит на стороне браузера в Javascript, что делает AngularJS идеальным партнером для любой серверной технологии.

Angular – это то, чем мог бы быть HTML, если бы на HTML разрабатывали приложения. HTML – замечательный декларативный язык для статических документов. Но, он не содержит ничего для создания приложений, и как результат разработка веб-приложения сводится к упражнению «что я должен сделать, чтобы обмануть браузер и сделать то, что я хочу».

В основном, статические документы становятся динамическими, используя два подхода:

  • Использование библиотеки: Набор функций облегчает написание приложений. Код приложения при необходимости вызывает функции библиотеки. (Пример: jQuery.)
  • Использование фреймворка: Это применение конкретной реализации веб-приложения, когда ваш код отвечает за детали. Здесь наоборот фреймворк это основа и он вызывает код приложения, который выполняет специфичную работу. (Пример: knockout, ember.)

Полноценное решение на стороне клиента

Angular не является каким-то одним элементом мозаики в построении клиентского веб-приложения. Он управляет всем кодом, который написан для DOM-элементов и AJAX-вызовов, и содержит этот код в хорошо организованной структуре. Это делает Angular чрезвычайно уверенным в том, как должны быть построены приложениия, выполняющие такие операции, как создание, чтение, обновление и удаление данных (CRUD). Но не смотря на эту уверенность, он настолько гибок, что шаблон постороения приложений может быть изменен по желанию разработчика. Вот стартовый набор инструментов, который предоставляет Angular:

  • Инструменты и техники для построения CRUD-приложений: связывание данных, базовые директивы, валидация форм, маршрутизация, глубокие ссылки, повторно используемые компоненты, внедрение зависимости.
  • Тестируемость: модульное тестирование (unit testing), тестирование end-to-end, фиктивные объекты (mocks), вспомогательные средства тестирования.
  • Базовое приложение с примером организации директорий и сценариями тестирования, в качестве стартовой точки разработки приложения.

Где Angular не рекомендуется использовать

Angular упрощает разработку приложения, предоставляя разработчику более высокий уровень абстракции. А любая абстракция жертвует гибкостью. Проще говоря, не любое приложение подходит Angular. Angular был создан в основном для CRUD-приложений. К счастью CRUD-приложения составляют 90% от всех веб-приложений. Чтобы понять подходит ли Angular для конкретного приложения, лучше объясним, когда приложению не нужен Angular.

Игры или редакторы с богатым пользовательским интерфейсом — это примеры, где идет очень интенсивная работа с DOM-элементами. Этот вид приложений сильно отличается от CRUD-приложений, и соответственно, не очень подходит для Angular. В таких случаях нужно что-то близкое к голому металлу, наверно jQuery окажется более удачным выбором.

Простейший пример приложения с Angular

Рассмотрим простое CRUD-приложение, которое содержит форму. Значения формы отслеживаются и используются для вычисления общего результата, который форматируется к определенному виду. Вот некоторые общие ключевые моменты, с которыми разработчик столкнется:

  • Связывание модели данных с пользовательским интерфейсом.
  • Чтение и проверка данных введенных пользователем.
  • Вычисление новых значений на основе данных модели.
  • Форматирование вывода в нужном формате.

Разберемся с тем, что происходит в примере выше. В теге с помощью директивы ng-app мы указали, что документ является приложением Angular. Также директива ng-app заставляет среду Angular автоматически выполнить инициализацию приложения.

Angular: архитектурные паттерны и лучшие практики

Создание масштабируемого программного обеспечения является сложной задачей. Когда мы думаем о масштабируемости в интерфейсных приложениях, мы можем думать о возрастающей сложности, все большем количестве бизнес-правил, растущем объеме данных, загружаемых в приложение, и больших группах, часто распространяемых по всему миру. Чтобы справиться с упомянутыми факторами для поддержания высокого качества доставки и предотвращения технического долга, необходима надежная и обоснованная архитектура. Сам по себе Angular — довольно самоуверенный фреймворк, заставляющий разработчиков делать все правильно. Тем не менее, есть много мест, где все может пойти не тем путем. В этой статье я представлю рекомендации высокого уровня по хорошо спроектированной архитектуре приложений Angular, основанной на передовых практиках и проверенных на практике шаблонах. Наша конечная цель в этой статье — научиться проектировать приложения Angular, чтобы поддерживать устойчивую скорость разработки и простоту добавления новых функций в долгосрочной перспективе. Для достижения этих целей мы будем применять:

  • правильные абстракции между прикладными уровнями,
  • однонаправленный поток данных,
  • управление реактивным состоянием,
  • модульная конструкция
  • шаблон умных и глупых компонентов.

Проблемы масштабируемости в front-end

Давайте подумаем о проблемах с точки зрения масштабируемости, с которыми мы можем столкнуться при разработке современных интерфейсных приложений. Сегодня интерфейсные приложения не просто отображают данные и принимают пользовательский ввод. Одностраничные приложения (SPA) предоставляют пользователям широкие возможности взаимодействия и используют бэкэнд в основном в качестве уровня сохраняемости данных. Это означает, что гораздо больше ответственности было перенесено на интерфейсную часть программных систем. Это приводит к растущей сложности внешней логики, с которой нам приходится иметь дело. Со временем растет не только количество требований, но и объем данных, которые мы загружаем в приложение. Кроме того, нам необходимо поддерживать производительность приложений, которая может быть легко повреждена.

Одним из решений описанных выше проблем является надежная системная архитектура. Но это связано с затратами, затратами на инвестиции в эту архитектуру с первого дня. Для нас, разработчиков, может быть очень заманчиво предлагать новые функции очень быстро, когда система еще очень мала. На этом этапе все просто и понятно, поэтому разработка идет очень быстро. Но если мы не заботимся об архитектуре, после нескольких ротаций разработчиков, сложных функций, рефакторингов, пары новых модулей, скорость разработки радикально замедляется. Ниже на диаграмме показано, как это обычно выглядело в моей карьере разработчика. Это не какое-то научное исследование, просто то, как я это вижу.

Архитектура программного обеспечения

Чтобы обсудить лучшие практики и шаблоны архитектуры, нам нужно ответить на вопрос, что такое архитектура программного обеспечения. Мартин Фаулер определяет архитектуру как «разбивку системы на части». Кроме того, я бы сказал, что архитектура программного обеспечения описывает, как программное обеспечение состоит из его частей и каковы правила и ограничения, связи между этими частями. Как правило, архитектурные решения, которые мы принимаем при разработке нашей системы, сложно изменить, поскольку система со временем растет. Вот почему очень важно обращать внимание на эти решения с самого начала нашего проекта, особенно если предполагается, что создаваемое нами программное обеспечение будет работать в течение многих лет. Роберт К. Мартин однажды сказал: истинная стоимость программного обеспечения — это его обслуживание. Обоснованная архитектура помогает снизить затраты на обслуживание системы.

Aбстракции высокого уровня

Первый способ, которым мы будем разлагать нашу систему, — через слои абстракции. Ниже на диаграмме изображена общая концепция этого разложения. Идея состоит в том, чтобы поместить надлежащую ответственность в надлежащий уровень системы: ядро, абстракцию или уровень представления. Мы будем смотреть на каждый слой независимо и анализировать его ответственность. Это разделение системы также диктует правила общения. Например, слой представления может общаться с основным слоем только через слой абстракции. Позже мы узнаем, каковы преимущества такого рода ограничений.

Уровень представления

Давайте начнем анализировать наш системный отказ от уровня представления. Это место, где живут все наши Angular компоненты. Единственные обязанности этого слоя — представлять и делегировать. Другими словами, он представляет пользовательский интерфейс и делегирует действия пользователя базовому уровню через уровень абстракции. Он знает, что отображать и что делать, но не знает, как следует обрабатывать взаимодействия с пользователем.

Ниже фрагмент кода содержит компонент CategoriesComponent использующий экземпляр SettingsFacade из уровня абстракции для делегирования взаимодействия с пользователем (через addCategory() и updateCategory() ) и представления некоторого состояния в его шаблоне (через isUpdating$ ).

Слой абстракции

Уровень абстракции отделяет уровень представления от основного уровня, а также имеет свои собственные определенные обязанности. Этот уровень предоставляет потоки состояния и интерфейса для компонентов в уровне представления, играя роль фасада. Такого рода фасадные песочницы какие компоненты могут видеть и делать в системе. Мы можем реализовать фасады, просто используя поставщиков классов Angular. Классы здесь могут быть названы, например, с помощью постфикса Facade SettingsFacade . Ниже вы можете найти пример такого фасада.

Интерфейс абстракции

Мы уже знаем основные обязанности для этого слоя; выставлять потоки состояния и интерфейса для компонентов. Начнем с интерфейса. Методы для работы с состоянием loadCashflowCategories() , addCashflowCategory() и updateCashflowCategory() абстрагируют детали управления состоянием и внешние вызовы API из компонентов. Мы не используем поставщиков API (например CashflowCategoryApi ) в компонентах напрямую, поскольку они находятся на основном уровне. Кроме того, изменения состояния не имеют значения для компонентов. Уровень представления не должен заботиться о том, как все делается, и компоненты должны просто вызывать методы из уровня абстракции, когда это необходимо (делегировать). Изучение открытых методов в нашем уровне абстракции должно дать нам быстрое понимание вариантов использования высокого уровня.

Топ-пост этого месяца:  Captcha плагины WordPress плагины для вставки Капчи на сайт

Но мы должны помнить, что уровень абстракции не место для реализации бизнес-логики. Здесь мы просто хотим связать уровень представления с нашей бизнес-логикой, абстрагируя то как он связан.

Состояние

Когда дело доходит до состояния, уровень абстракции делает наши компоненты независимыми от решения по управлению состоянием. Компонентам дают Observables с данными для отображения в шаблонах (обычно с конвейером async ), и им должно быть все равно, откуда эти данные. Для управления нашим состоянием мы можем выбрать любую библиотеку управления состоянием, которая поддерживает RxJS (например, NgRx), или просто использовать BehaviorSubjects для моделирования нашего состояния. В приведенном выше примере мы используем объект состояния, который внутренне использует BehaviorSubjects (объект состояния является частью нашего основного уровня). В случае с NgRx мы будем отправлять действия в хранилище.

Такая абстракция дает нам большую гибкость и позволяет изменять способ управления состоянием, даже не затрагивая уровень представления. Можно даже легко перейти на серверную часть в реальном времени, например Firebase, что делает наше приложение real-time. Мне лично нравится работать с BehaviorSubjects, чтобы управлять состоянием. Если позднее, на каком-то этапе разработки системы, возникнет необходимость использовать что-то еще, с такой архитектурой, будет очень легко провести рефакторинг.

Стратегия синхронизации

Теперь давайте подробнее рассмотрим другой важный аспект уровня абстракции. Независимо от выбранного нами решения по управлению состоянием мы можем реализовывать обновления пользовательского интерфейса либо оптимистично, либо пессимистично. Представьте, что мы хотим создать новую запись в коллекции некоторых сущностей. Эта коллекция была получена из бэкэнда и отображена в DOM. При пессимистичном подходе мы сначала пытаемся обновить состояние на стороне сервера (например, с помощью HTTP-запроса), а в случае успеха мы обновляем состояние в приложении веб-интерфейса. С другой стороны, при оптимистичном подходе мы делаем это в другом порядке. Во-первых, мы предполагаем, что обновление бэкэнда выполнится успешно и немедленно обновит состояние внешнего интерфейса. Затем мы отправляем запрос на обновление состояния сервера. В случае успеха нам не нужно ничего делать, но в случае неудачи, нам нужно откатить изменения в нашем приложении и сообщить пользователю об этой ситуации.

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

Кэширование

Иногда мы можем решить, что данные, которые мы получаем из бэкэнда, не будут частью состояния нашего приложения. Это может быть полезно для данных предназначенных только для чтения (read-only), которыми мы вообще не хотим манипулировать и просто передаем (через уровень абстракции) компонентам. В этом случае мы можем применить кеширование данных на нашем фасаде. Самый простой способ добиться этого — использовать оператор RxJS shareReplay() , который будет воспроизводить последнее значение в потоке для каждого нового подписчика. Взгляните на фрагмент кода RecordsFacade , с помощью RecordsApi для извлечения, кэширования и фильтрации данных для компонентов.

Подводя итог, что мы можем сделать на уровне абстракции:

  • раскрыть методы для компонентов, в которых мы:
    • делегируем выполнение логики на основной уровень,
    • принять решение о стратегии синхронизации данных (оптимистично или пессимистично),
  • выставить потоки состояния для компонентов:
    • выбрать один или несколько потоков состояния пользовательского интерфейса (и объединить их при необходимости),
    • кешировать данные из внешнего API.

Как мы видим, уровень абстракции играет важную роль в нашей многоуровневой архитектуре. В нем четко определены обязанности, которые помогают лучше понять и рассуждать о системе. В зависимости от вашего конкретного случая, вы можете создать один фасад для каждого модуля Angular или один для каждого объекта. Например, SettingsModule может содержать только SettingsFacade , если он не слишком раздутый. Но иногда может быть лучше создать более детальные фасады абстракции для каждого объекта индивидуально, как UserFacade для объекта User .

Основной слой

Последний слой является основным слоем. Вот где реализована основная логика приложения. Все манипуляции с данными и связь с внешним миром происходят здесь. Если бы для управления состоянием мы использовали решение, такое как NgRx, то здесь есть место для определения нашего state, action и reducer. Поскольку в наших примерах мы моделируем состояние с помощью BehaviorSubjects, мы можем инкапсулировать его в удобный класс состояний. Ниже вы можете найти пример SettingsState из основного слоя.

На уровне ядра мы также реализуем HTTP-запросы в форме классов поставщиков. Этот вид класса может иметь постфикс Api или Service . Сервисы API несут только одну ответственность — это связь с конечными точками API и ничего больше. Мы должны избегать кеширования, логики или манипулирования данными здесь. Простой пример API-сервиса можно найти ниже.

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

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

Однонаправленный поток данных и управление реактивным состоянием

Следующий принцип, который мы хотим внедрить в нашу систему, касается потока данных и распространения изменений. Сам Angular использует однонаправленный поток данных на уровне представления (через привязки), но мы наложим аналогичное ограничение на уровень приложения. Вместе с управлением реактивным состоянием (на основе потоков) оно даст нам очень важное свойство системы — согласованность данных. Ниже на диаграмме представлена ​​общая идея однонаправленного потока данных.

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

Как мы знаем из предыдущих глав, над уровнем представления находится базовый уровень, на котором реализована логика нашего приложения. Есть сервисы и провайдеры, которые работают с нашими данными. Что если мы применим тот же принцип манипулирования данными на этом уровне? Мы можем разместить данные приложения (состояние) в одном месте «над» компонентами и распространить значения до компонентов через наблюдаемые потоки (Redux и NgRx называют это место хранилищем). Состояние может распространяться на несколько компонентов и отображаться в нескольких местах, но никогда не изменяться локально. Изменение может произойти только «сверху», а компоненты ниже только «отражают» текущее состояние системы. Это дает нам важное свойство системы, упомянутое ранее — согласованность данных — и объект состояния становится единственным источником правды. Практически говоря, мы можем отображать одни и те же данные в нескольких местах и ​​не бояться, что значения будут отличаться.

Наш объект состояния предоставляет методы для служб в нашем основном уровне для управления состоянием. Всякий раз, когда необходимо изменить состояние, это может произойти только путем вызова метода для объекта состояния (или отправки действия в случае использования NgRx). Затем изменение распространяется «вниз» через потоки на уровень представления (или любую другую услугу). Таким образом, наше хранилище реагирует. Более того, с помощью этого подхода мы также повышаем уровень предсказуемости в нашей системе из-за строгих правил манипулирования и совместного использования состояния приложения. Ниже вы можете найти фрагмент кода, моделирующий состояние с помощью BehaviorSubjects.

Давайте повторим шаги обработки взаимодействия с пользователем, имея в виду все принципы, которые мы уже представили. Во-первых, давайте представим, что на уровне представления есть какое-то событие (например, нажатие кнопки). Компонент делегирует выполнение на уровень абстракции, вызывая метод на фасаде settingsFacade.addCategory() . Затем фасад вызывает методы для служб на уровне ядра — categoryApi.create() и settingsState.addCategory() . Порядок вызова этих двух методов зависит от выбранной нами стратегии синхронизации (пессимистичной или оптимистической). Наконец, состояние приложения распространяется до уровня представления через наблюдаемые потоки. Этот процесс четко определен.

Модульная конструкция

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

Наше приложение по техническим причинам имеет также два дополнительных модуля. У нас есть объект CoreModule , который определяет наши одноэлементные сервисы, компоненты одного экземпляра, конфигурацию и экспорт любых сторонних модулей, необходимых для AppModule . Этот модуль импортируется только один раз в AppModule . Второй модуль SharedModule содержит общие компоненты / каналы / директивы, а также экспортирует часто используемые Angular модули (например CommonModule ). SharedModule может быть импортирован любым функциональным модулем. На диаграмме ниже представлена ​​структура импорта.

Структура каталогов модулей

На диаграмме ниже показано, как мы можем разместить все части нашего SettingsModule внутри каталогов. Мы можем поместить файлы внутри папок с именем, представляющим их функцию.

Умные и глупые компоненты

Последний архитектурный образец, который мы представляем в этой статье, касается самих компонентов. Мы хотим разделить компоненты на две категории в зависимости от их ответственности. Во-первых, это умные компоненты (или контейнеры). Эти компоненты обычно:

  • работают с фасадами и другими услугами
  • общаются с основным слоем
  • передают данные в глупые компоненты
  • реагируют на события от глупых компонентов
  • являются маршрутизируемыми компонентами верхнего уровня (но не всегда!)

Ранее представленный CategoriesComponent является умным. Он внедрил SettingsFacade и использует его для связи с основным уровнем нашего приложения.

Во второй категории есть глупые компоненты. Их единственная обязанность состоит в том, чтобы представить элемент пользовательского интерфейса и делегировать взаимодействие пользователя «вверх» умным компонентам через события. Подумайте о нативном элементе HTML, как Click me . Этот элемент не имеет никакой конкретной реализованной логики. Мы можем думать о тексте « Click me » как о входных данных для этого компонента. Он также имеет некоторые события, на которые можно подписаться, например, событие клика. Ниже вы можете найти фрагмент кода простого глупого компонента с одним входом и без выходных событий.

Резюме

Мы рассмотрели несколько идей о том, как спроектировать архитектуру Angular приложения. Эти принципы, при правильном применении, могут помочь поддерживать скорость устойчивого развития с течением времени и позволят легко предоставлять новые функции. Пожалуйста, не относитесь к ним как к некоторым строгим правилам, а скорее к рекомендациям, которые можно использовать, когда они имеют смысл.

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

Angular компоненты: создание, основы работы с приложением, примеры кода

Angular 2 – это open source фреймворк для создания мобильных, десктопных и веб-приложений.

Angular 2 хоть и является приемником AngularJS 1.x, но может быть рассмотрен как совершенно новый фреймворк, созданный на основе лучших наработок из AngularJS 1.x. Отсюда пошло изменение в его именовании – теперь используется просто имя Angular, что указывает именно на Angular 2. В свою очередь, имя AngularJS ссылается на прошлую версию AngularJS 1.x. В этой статье мы будем использовать имена Angular и Angular 2 попеременно, но они оба ссылаются на Angular 2.

В данной статье мы создадим небольшое Angular 2 веб-приложение, которое позволит делать следующие вещи:

  • Быстро создавать новые записи, используя поле ввода, простым нажатием клавиши Enter
  • Выбирать статус записи
  • Удалять ненужные записи
Топ-пост этого месяца:  Гугл Аналитика как установить статистику на блог Wordpress

По этой ссылке доступно демо приложения. Все исходные коды приложения можно найти в GitHub репозитории.

Итак, давайте начнём!

Angular CLI

Одним из самых простых способов создать новое Angular 2 приложение – использовать интерфейс командной строки (CLI) для Angular от разработчиков этого фреймворка, который позволит:

  • Создать стартовый шаблон со всем необходимым кодом для нового Angular 2 приложения
  • Добавить необходимые компоненты, директивы, сервисы, pipes и т.д. к существующему приложению

Для установки Angular CLI необходимо запустить в командной строке:

В данном случае, параметр -g указывает на то, что этот пакет установится глобально и после этого нам будет доступна команда ng .

Чтобы проверить правильность установки, можно выполнить такую команду:

Если всё установлено верно, то будет выведена версия пакета.

При необходимости, вы можете посетить официальную документацию для более детального ознакомления c Angular CLI.

Генерируем наше приложение

Теперь, когда у нас есть установленный Angular CLI, мы можем использовать его для создания стартового шаблона для нашего приложения:

Этой командой мы создадим новую директорию для нашего проекта со всем необходимым для начала работы.

После генерации шаблона, выполним следующие команды:

Тем самым, у нас будет запущенный локальный сервер, который обслуживает наше приложение и доступен по адресу http://localhost:4200/. Также при изменении кода, наше приложение будет автоматически перезагружаться, что добавит немного комфорта в процесс разработки.

Составные части Angular

При выполнении команды ng new , Angular CLI создал для нас стартовый Angular 2 шаблон, но это только лишь одна из полезных возможностей, предоставляемых этим инструментом. Этот инструмент также поможет нам добавить дополнительные составные части в существующее Angular приложение, при помощи команды ng generate :

Если вы не знакомы с основными строительными блоками Angular 2 приложения, то крайне рекомендую ознакомиться с быстрым стартом Angular 2 сначала.

Для нашего приложения нам понадобятся:

  • Todo класс для представления каждой отдельной записи
  • TodoService для создания, обновления и удаления записи
  • TodoApp компонент для отображения пользовательского интерфейса

Итак, давайте добавим последовательно все эти компоненты в наше приложение.

Создание класса Todo

По той причине, что мы используем TypeScript, у нас есть возможность создать класс для представления Todo записей. Поэтому, воспользуемся возможностями Angular CLI для генерации Todo класса:

Что создаст следующие файлы:

Давайте откроем файл src/app/todo.ts и заменим его содержимое на:

В нашем случае, каждая Todo запись имеет три свойства:

  • id : числовой тип, уникальный ID каждой записи
  • title : строковый тип, название записи
  • complete : булевый тип, статус для записи – завершена задача или нет

Использование конструктора позволит нам при создании экземпляра класса определить нужные значения, например:

Angular CLI также создал для нас src/app/todo.spec.ts файл, поэтому давайте добавим в него юнит-тест, чтобы убедиться в работоспособности логики конструктора:

Для проверки того, что наш код работает так, как мы ожидали, запустим юнит-тесты командой:

Которая запустит окружение для тестирования Karma и выполнит все наши тесты.

Если тесты не были пройдены успешно, то, возможно, вы допустили какую-то ошибку в коде приложения. Просто сравните ваш код с кодом, находящимся в репозитории приложения: https://github.com/sbogdanov108/angular2_crud

Теперь, когда у нас есть Todo класс, давайте создадим Todo сервис, который будет управлять всеми записями нашего приложения.

Создание Todo сервиса

TodoService , который будет нами создан, должен отвечать за управление Todo записями. В будущей статье, мы разберём, как взаимодействовать с REST API сервисом, но в рамках данной статьи, мы используем простое хранение всех данных приложения в оперативной памяти.

Приступим к генерации нового сервиса с помощью Angular CLI:

Этой командой мы создадим файлы:

Сейчас нам нужно добавить логику работу сервиса TodoService в файл src/app/todo.service.ts :

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

И чтобы убедиться, что написанная нами логика работает, давайте добавим несколько юнит-тестов в файл src/app/todo.service.spec.ts , который был сгенерирован Angular CLI.

Так как Angular CLI уже создал для нас заготовку кода, всё, что остаётся сделать – реализовать нужные тесты:

Karma поставляется с встроенным и предварительно сконфигурированным фреймворком для тестирования Jasmine. Вы можете ознакомиться с документацией Jasmin для лучшего понимания синтаксиса этого фреймворка.

Чтобы проверить правильность работы нашей бизнес-логики, заново запустим наши юнит-тесты:

Отлично, всё работает! Теперь самое время создать интерфейс нашего приложения.

В Angular 2 интерфейс приложения реализуется с помощью компонентов.

Создание TodoApp компонента


И снова давайте используем Angular CLI для генерации компонента:

Эта команда создаст следующие файлы:

Шаблоны и стили также могут быть включены во внутрь файлов скриптов. Angular CLI создаёт несколько отдельных файлов по умолчанию, поэтому, в этой статье, мы будем использовать отдельные файлы.

Давайте начнём с добавления шаблона для компонента в файл src/app/todo-app/todo-app.component.html :

Далее приведено короткое представление Angular синтаксиса для шаблонов, в случае, если вы ещё с ним не сталкивались:

  • [свойство]=»выражение» : назначить свойству результат выражения
  • (событие)=»утверждение» : выполнить утверждение, когда произойдёт событие
  • [(свойство)]=»выражение» : создать двухстороннее связывание с указанным выражением
  • [ : добавить ваш_класс CSS к этому элементу, когда выражение будет истинным
  • [style.color]=»выражение» : назначить свойство CSS color в зависимости от результата выполнения выражения

Если вам не знаком синтаксис Angular для шаблонов, то необходимо ознакомится с официальной документацией на эту тему.

Давайте посмотрим, что происходит в нашем шаблоне. На самом верху есть поле ввода для создания новой записи:

  • [(ngModel)]=»newTodo.title» : добавляет двухстороннее связывание между значением input и newTodo.title
  • (keyup.enter)=»addTodo()» : говорит Angular, чтобы он выполнил метод addTodo() , когда клавиша Enter была нажата в поле ввода

Не беспокойтесь пока о том, откуда появились newTodo или addTodo() – мы вскоре их рассмотрим более подробно. Просто попытайтесь понять смысл шаблона.

Далее следует секция для вывода записей todo:

  • *ngIf=»todos.length > 0″ : показать элемент section и всё его содержимое, только при условии, что есть хотя бы одна запись todo

Внутри этой секции, мы просим Angular сгенерировать li элементы для каждой записи:

  • *ngFor=»let todo of todos» : в каждой итерации цикла, мы проходимся по записям todos и назначаем конкретную запись в переменную todo
  • [ : применить класс CSS complete к элементу li , при условии, когда todo.complete является истиной

И наконец, мы отображаем информацию о каждой записи внутри цикла ngFor :

  • (click)=»toggleTodoComplete(todo)» : выполнить toggleTodoComplete(todo) при клике на этом чекбоксе
  • [checked]=»todo.complete» : назначить значение todo.complete свойству checked
  • (click)=»removeTodo(todo)» : выполнить метод removeTodo(todo) , когда была нажата кнопка

Хорошо, теперь давайте вздохнём �� Мы прошлись через довольно-таки большое количество синтаксиса.

Если у вам возникнет желание изучить более подробно синтаксис шаблонов Angular, то отличным вариантом будет начать с официальной документации по шаблонам.

На данный момент, вы могли удивиться – как же выражения addTodo() и newTodo.title могут быть выполнены. Ведь мы ещё не определили их, поэтому, откуда Angular узнает, что они значат?

Это именно то место, где в дело вступает контекст выражения. Контекст выражения компонента является экземпляром компонента. И в свою очередь, экземпляр компонента является экземпляром класса компонента.

Класс компонента нашего TodoAppComponent определён в src/app/todo-app/todo-app.component.ts .

Angular CLI уже создал для нас заготовку класса TodoAppComponent :

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

Нам понадобится экземпляр TodoService, поэтому, давайте начнём со вставки его в наш компонент.

Первым делом, мы импортируем TodoService класс и определим его в массиве providers декоратора Component :

В компоненте TodoAppComponent будет произведена вставка зависимости TodoService , таким образом, при необходимости использования этого сервиса будет создан его одиночный экземпляр.

Для системы зависимостей Angular существует множество способов использования. Применённый нами выше синтаксис является укороченной нотацией провайдера класса, таким образом, используется singleton паттерн для работы с зависимостями. Для более детального ознакомления с зависимостями Angular можно рассмотреть документацию на эту тему.

Теперь, когда мы объявили зависимость, можно использовать экземпляр TodoService в конструкторе TodoAppComponent :

Сейчас мы можем реализовать всю необходимую логику для работы нашего шаблона, добавив свойства и методы в TodoAppComponent класс:

Сначала при инициализации класса компонента, мы назначаем свойству newTodo экземпляр класса Todo с помощью кода new Todo() . Это то самое newTodo, которому мы добавили двухстороннее связывание в шаблоне:

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

Потом мы реализовали все необходимые методы, которые используются в нашем шаблоне.

Реализация этих методов является очень короткой и легкой для понимания, так как мы поручили обработку всей логики работы сервису todoService.

Делегирование бизнес-логики сервису, является хорошей практикой в программировании и это позволит нам централизованно управлять и тестировать эту логику.

Теперь на осталось сделать пару шагов, чтобы получить готовое приложение.

Последние штрихи

Для начала найдём в нашем проекте файл src/app/angular2-todo-app.component.ts и внесём в него изменения:

Главные изменения состоят в том, что мы импортировали созданный нами компонент TodoAppComponent для вывода записей, и внесли в декоратор Component указание использовать класс TodoAppComponent для обработки директивы app-todo , описанной в этом классе.

Теперь откроем файл src/app/angular2-todo-app.component.html и заменим всё его содержимое на вызов директивы:

Итак, у нас получилось работающее приложение, правда без стилей.

Добавим предварительно подготовленные стили, которые можно взять по ссылке. И вставим их в файл src/app/todo-app/todo-app.component.css . После сохранения у нас получится полностью готовое и работоспособное приложение.

И до того, как мы закончим этот туториал, давайте попробуем сделать одну интересную вещь с помощью Angular CLI.

Деплой приложения на GitHub Pages

Angular CLI позволяет произвести деплой приложения на GitHub Pages с минимум движений, буквально одной командой.

Для начала нам нужно создать репозиторий на GitHub с именем, которое указано в файле package.json :

Затем выполнить команду:

Команда github-pages:deploy говорить Angular CLI сделать билд статической версии Angular приложения и выполнить его push в бранч gh-pages нашего GitHub репозитория.

Теперь, созданное нами приложение доступно по адресу: https://sbogdanov108.github.io/angular2_crud/

Просто чудесная возможность для быстрого развёртывания приложения, не правда ли?

Подводя итог…

Angular 2 – крайне мощный инструмент для создания приложения, без всякого сомнения.

В этой статье, мы рассмотрели много разных тем и пришло время подвести краткое резюме тому, что изучили:

  • Мы узнали, как установить Angular CLI и как много времени этот инструмент может сохранить для нас, при создании нового приложения или добавление функционала к существующему
  • Мы изучили, как реализовать бизнес-логику в сервисах Angular и как произвести тестирование этой логики используя юнит-тесты
  • Как использовать компоненты для взаимодействия с пользователем и каким образом делегировать логику работы сервису, используя вставку зависимостей
  • Мы изучили основы синтаксиса шаблонов Angular и немного коснулись темы работы зависимостей в Angular
  • И под конец, мы узнали, как можно быстро развернуть наше приложение на GitHub Pages

Осталось много того, о чём ещё хотелось бы поговорить, но это уже темы для следующих статей:

  • Взаимодействие с REST API бэкэндом, используя Angular 2 HTTP сервис
  • Фильтрация записей todo с помощью Angular pipes
  • Реализация навигации для создания многостраничного приложения

И ещё много другого…

Исходные коды приложения доступны в GitHub репозитории по ссылке.

При создании статьи были использованы следующие источники:

Angular CLI создание проекта: основные команды

Сегодня начинаем разбирать весьма новый фреймворк JavaScript — Angular. Для того чтобы не писать кучу лишнего кода самому, чтобы его запустить и не тратя на это время — сначала мы изучим инструмент Angular CLI.

Что такое Angular CLI

Это инструмент созданный командой Google, который помогает увеличить скорость работы с проектом. Чтобы с ним работать вам придется изучить несколько команд, которые прописываются в командной строке.

У вас наверное созрел вопрос, а что именно он может? С помощью его вы можете:

  • Создание стартового проекта.
  • Создание конфигурационных файлов для деплоймента (deployment — prodaction и development).
  • Сгенерировать файлы для тестирования.
  • Проделать минимизацию приложения.
  • Создавать шаблонные файлы: сервисов (service), компонентов (component), навигационных файлов (route).

Также у него в арсенале имеется Webpack, который пользуется большой популярностью. Он нужен чтобы компилировать и запускать проекты во время разработки.

Как видите это очень мощный инструмент в разработке больших проектов, и на старте проекта.

Установка Angular CLI

Для того чтобы начать необходимо установить:

  1. Node js — серверная часть Javascript.
  2. Npm — менеджер пакетов, без которого мы далеко не уйдем.

Npm подтянется вместе с Node js при его установки.

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

package.json — может хранить все зависимости, которые используются для работы с проектом. Также в нем можно найти — имя проекта, версия, скрипты и т.д.

Заходим на сайт — nodejs. Здесь вас ждет две версии Node js — LTS и Current. Выбирайте LTS и устанавливайте ее.

Топ-пост этого месяца:  Первая страница выдачи Google на 45% состоит из https-сайтов

Теперь давайте установим Angular CLI на ваш ПК. Для этого вам нужно перейти в командною строку. Это можно сделать двумя способами:

Или второй способ:

  1. Зажать shift на клавиатуре
  2. Нажать правой кнопкой мыши по пустому месту в папке или рабочем столе
  3. В появившимся списке нажать на пункт «Открыть окно команд».

Два данных способа относятся к операционной системе Windows

После открытия командной строки вводим строку ниже. Она представляет собой запрос на скачивание пакета npm:

  • i это укороченная форма слова install (установить).
  • Далее идет название нашего пакета — @angular/cli .
  • -g означает установить данный пакет глобально на весь компьютер. Иначе мы бы установили его только в папку, из которой была вызвана данная команда и смогли использовать функционал только там.

Эта библиотека большая, поэтому вас понадобиться подождать несколько минут для ее установки.

Вот и все работы были сделаны. Теперь можем перейти рассматривать функционал установленного пакета.

Команды Angular CLI

Все команды должны начинаться со слова — ng . Таким образом мы показываем, что именно хотим использовать Angular CLI.

Вот список всех команд, которые вам понадобиться знать:

ng new [name] — сгенерирует проект с данным названием — [name] . Вместе с этим установит необходимые зависимости в директорию node_modules — это может занять несколько минут.

Это будет зависеть от скорости вашего интернета соединения.

Если вы зайдете в данный проект, то увидите такую картину:

ng serve — запускает Webpack, который в свою очередь собирает файлы вашего проекта и переносит их в оперативную память вашего компьютера. Если вы замените какой-то файл, то он заново будет пересобирать ваш проект.

Перейдите на localhost:4200 в браузере и сможете увидеть ваш проект.

ng serve —prod — также запустит Webpack, но уже будет оптимизировать ваш проект. Таким образом можно уменьшить размер проекта от одной до нескольких сотен килобайт. В нашем случае на

ng build — собирает все ваши файлы проекта и переносит их в папку dist. Далее вы можете делать с ними все что угодно — например, залить куда-нибудь на хостинг.

При ng serve мы ни как не можем пощупать собранные файлы.

ng build —prod — оптимизирует файлы, больше ничем не отличается.

ng generate [spec_file] [name] — создает [spec_file] с названием [name] и автоматически добавляет(производит import) его в модуль.

[spec_file] — это левая колонка таблицы

Файл Запрос
Component ng g component name
Service ng g service name
Module ng g module name
Pipe ng g pipe name
Class ng g class name
Guard ng g guard name
Interface ng g interface name
Enum ng g enum name
Directive ng g directive name
Routing module ng g module name —routing

Со всем этими файлами вы познакомитесь позже.

Замена стилизации в проектах

Автоматически Angular CLI генерирует стили с типом .css , но его можно поменять на другие более удобные для вас. Например:

Таким образом у нас есть еще один бонус при использовании Angular CLI. Чтобы изменить стилизацию добавьте такой флаг — —style=[name] :

Создание Angular 5 приложения

Angular — это фреймворк позволяющий быстро и удобно разрабатывать одностраничные веб приложения. В своей основе он использует язык программирования TypeScript. Давайте рассмотрим процесс создания процесс создания SPA-приложения (Single Page Application) с помощью данного фреймворка от идеи до публикации.

Данная статья достаточно объемна, поэтому будет разбита на несколько частей и опубликована в моем блоге. Для разработки будет использоваться Angular 5, Visual Studio 2020. Итак, нашей целью является разработка простого приложения представляющее собой доску объявлений, куда можно публиковать короткие объявления. Приступ. Перед началом работы не забываем, что предварительно необходимо установить node.js.

Часть 1 — Создание проекта и первоначальное выделение компонентов на основе статической html-старицы

Часть 2 — Выделение более специализированных компонентов, реализация взаимодействия с базой данных

Часть 3 — Завершение выделения всех компонентов, публикация приложения.

Готовые примеры приложений на Angular?

Джон Голт: ну так придумайте. Те штуки которые мне нужны вы просто не сделаете. А что вам нужно — я без понятия.

todomvc — это простое приложение на котором можно много чего попробовать. А самое полезное — есть десятки готовых реализаций и всегда можно сравнить решения.

CAMOKPYT: увы в опенсурсе подобных проектов банально нет. Подавлюящее количество проектов где было бы прикольно посмотреть исходники закрыто NDA, и вам это прекрасно известно.

А что до архитектуры — stateless-компоненты, unidirectional data flow (redux например) и вперед. ну и не забываем про готовые решения.

Опять же тесты и ходить по граблям и получать экспириенс. Вообще помимо JS надо таки знать хоть что-то об архитектуре и подходах к разработке и неплохо так знать JS. Подавляющее же количество разработчиков сразу после установки плагинов на jquery начинают писать поделки на ангуляре. Как думаете, какое будет у них качество?.

CAMOKPYT: я пишу на Angular вот уже 2 года, и это безумно эффективно если знать что делаешь.

По поводу «зачем мне фреймворе, если все что сложнее тудушек надо писать руками» — я вам даже больше скажу, и todo-ки придется писать руками. Вот только огромный процент рутины возьмет на себя angular.

CAMOKPYT: не ну если хочется делать UI аля 90-е то согласен. Но мы же говорим о приличных приложениях, с какой-то минимальной бизнес логикой на клиенте и т.д. И пусть разработка фронтэнда усложняется если сравнивать со старыми добрыми формами и jquery, то бэкэнд сильно упрощается и по итогу мы получаем в сумме профит.

Пример — да, для первого ангуляра. Для второго суть будет примерно та же, только не надо будет кастыли вставлять для ngModel.

CAMOKPYT: сделать плохо можно всегда и используя что угодно.

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

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

Что до того что «кода столько же» — зато код проще, меньше побочных эффектов, проще отлаживать и, как вы уже заметили, проще тестировать.

Качество не в количестве кода меряется а в возможности скейлиться как никак.

Основы AngularJS на практике

Введение

AngularJS – фреймворк-библиотека Javascript, разработанная для создания одностраничных приложений на основе MVC (Model-View-Controller) шаблона.

Будем осваивать данную технологию на практике.

Создадим HTML страничку со стандартной структурой. Далее нам нужно преобразовать ее в одностраничное приложение. Для этого подключим AngularJS к своей странице, добавив в

тег с данным кодом:

script src =» http :// ajax . googleapis . com / ajax / libs / angularjs /1.3.14/ angular . min . js «>

Следующим шагом мы явно укажем на то, что наша страница является AngularJS приложением. Нужно добавить ng-app директиву, которой мы обозначим корневой элемент приложения. Зачастую таким элементом выступает тег или же тег . Добавим эту директиву к :

meta charset =»utf-8″>

script src =»http://ajax.googleapis.com/ajax/libs/angularjs/1.3.14/angular.min.js»>

Проверим, все ли работает, добавив небольшое выражение для подсчета произведения чисел 123 и 45. В AngularJs все выражения записываются в двойных скобках. Добавим в параграф со следующим содержимым:

p > Результат произведение чисел 123 и 45 равен : <<123 * 45 >> p >

Запустим в браузере:

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

AngularJS позволяет разработчику легко взаимодействовать с пользовательским вводом. Для этого есть соответствующая директива ng-model , которая связывает значения HTML элементов контроля (teaxtarea, input etc.) с приложением. Использовать эти данные поможет директива ng-bind, добавив эти данные во View ( элемент MVC ) и отобразив их на странице.

Применим полученные знания на практике. В созданный ранее шаблон добавим поле для ввода input > с директивой ng-model и параграф для вывода данных c директивой ng-bind.

meta charset =»utf-8″>

script src =»http://ajax.googleapis.com/ajax/libs/angularjs/1.3.14/angular.min.js»>

p > Ввведте свое имя: p >

input type =»text» ng-model =»yourName»>

p > Здравствуй, span ng-bind =»yourName»> span > p >

Откроем в браузере:

Теперь попробуйте ввести свое имя в поле для ввода.

Давайте добавим в данный пример дефолтное значение имени, к примеру Анна. Сделаем это, конечно же, с помощью директивы ng-init , которая позволяет инициализировать любую переменную AngularJS приложения.

В строку добавим директиву ng-init .

input type =» text » ng — model =» yourName » ng — init =» yourName =’ A нна'»>

Посмотрим изменения в браузере:

Теперь мы имеем значение по дефолту – Анна, но все так же можем изменять его:

Вывод данных в этом примере можно сделать еще одним способом, а именно, использовав выражение. Заменим на <>.

Открыв страницу, мы не увидим абсолютно никаких изменений, а все потому, что выражения в AngularJS связывают данные со страничкой точно так же, как и ng-bind директива.

Как упоминалось в статье ранее, AngularJS строит приложения на основе MVC. Часть модель – представление (Model — View) определяется с помощью директивы ng-app . Контроллер в свою очередь определяется директивой ng-controller .

Рассмотрим пример с использованием контроллера страницы.

Создадим страничку со списком гостей, которых Вы пригласите на свой день рождения.

К созданному ранее шаблону добавим контроллер, а так же установим имя для приложения. В тег внесем следующие изменения:

html ng-app =»firstApp» ng-controller =»firstController»>

Далее добавим с типом text для введения имени гостя и еще один с типом submit для добавления гостя в список. Также добавим

script src =»http://ajax.googleapis.com/ajax/libs/angularjs/1.3.14/angular.min.js»> script >

body ng-app =»firsApp» ng-controller =»firstController»>

h2 > Мои гости: h2 >

form ng-submit =»addGuest()»>

input type =»text» ng-model =»guestsInput» size =»50″ placeholder =»Введите имя гостя»>

input type =»submit» value =»Добавить гостя»>

div ng-repeat =»guest in listOfGests»>

input type =»checkbox» ng-model =»guest.come»> span ng-bind =»guest.guestName»> span >

p > button ng-click =»remove()»> Удалить гостя button > p >

Осталось добавить скрипт, который будет содержать функции для работы с элементами нашего приложения. Замечу, что все функции будут расположены в контроллере приложения.

Скопируйте и добавьте после закрывающегося тега параграфа с кнопкой

p > button ng — click =» remove ()»> Удалить гостя button > p >

var app = angular.module( ‘firsApp’ , []);

app.controller( ‘firstController’ , function ($scope) <

var countOfGuests = 1;

var oldGuests = $scope.listOfGests;

angular.forEach(oldGuests, function (guest) <

if (!guest.come) $scope.listOfGests.push(guest);

alert( » Маленькая вечеринка тоже не плохо ! Не печалься! Лучших друзей не бывает много!» );

> else if (countOfGuests >= 9)<

alert( «Праздник?! ВЕЧЕРИНИЩЕ!» );

alert ( «Узкий круг самых близких, это всегда хорошо!» );

В данном коде у нас есть три функции: добавление и удаление гостя и проверка количества гостей.

В функции добавления мы берем введенные данные guestsInput и добавляем их в лист listOfGests. Устанавливаем значение чекбокса в false (в нашем случае, это значит, что человек придет / если значение true, то есть галочка стоит — значит не придет), после чего очищаем поле ввода. Далее увеличиваем счетчик гостей и вызываем функцию проверки их количества.

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

Функция проверки количества гостей очень проста, поэтому подробнее мы ее разбирать не будем.

Давайте откроем пример в браузере и поработаем с ним:

Добавим несколько гостей:

С изменением количества гостей содержимое оповещений будет меняться.

Когда вы добавите больше 9 друзей, тогда увидите такое оповещение :

Поздравляем, вот Вы и создали свое первое одностраничное приложение с помощью AngularJS!

Добавить комментарий