Angular2 — angular2 и coffeescript


Содержание

Начинаем работать с Angular 2 и TypeScript

Russian (Pусский) translation by Ellen Nelson (you can also view the original English article)

Мир фронт-енд разработки перевернулся с ног на голову, когда вышел AngularJS, объединив ряд новых или недавних обычаев разработки веб-приложений в мощную и удобную в использовании инфраструктуру (фреймворк). В версии 2, команда Angular переписала все с нуля с совершенно новой системой. Многие идеи Angular остаются теми же, но API и опыт разработчиков очень разные.

Посмотрите этот видео урок из моего курса, Начинаем работать с Angular 2, где мы рассмотрим как TypeScript работает c Angular 2. А также я показываю некоторые основной синтаксис TypeScript.

Начинаем работать с Angular 2 и TypeScript

Насколько TypeScript соответствует Angular 2

Angular 2 построен на TypeScript, который использует синтаксис ES6 и компилируется в обычный JavaScript. Стандарт ES5 JavaScript также подходит для TypeScript, поэтому вы всё ещё можете использовать ваш существующий код.

TypeScript отличается системой типизации (система типов). Хотя это не обязательно, я рекомендую вам использовать систему типизации в ваших проектах. Система типов полезна в больших проектах, для определения ожидаемого типа значения в вашем коде.

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

TypeScript в действии

Прежде чем мы рассмотрим небольшой кусок синтаксиса TypeScript, мы обсудим файлы tsconfig.json и typings.json, на которых мы основываем наши проекты.

Файл tsconfig.json

Сначала будет скомпилирован, файл tsconfig.json, которым управляется TypeScript. Ключ target в параметрах компилятора указывает компилятору на создание ES5 JavaScript.

Module определяет стиль загрузчика модулей, который мы используем; другие параметры — общие JS, AMD и UMD. ModuleResolution определяет, как модули будут расставлены, а sourceMap генерирует соответствующий файл карты, который отображает сгенерированный JavaScript в его исходный TypeScript. EmitDecoratorMetadata и experimentalDecorators позволяют нам использовать декораторы в нашем приложении. Мы поговорим о декораторах чуть позже. RemoveComments определяет, будут ли удалены какие-либо комментарии, добавленные при компиляции, и, наконец — noImplicitAny . Это параметр определяет, как будет вести себя компилятор, если он не сможет определить тип. Так как TypeScript может быть типизирован, если мы не укажем тип, он должен определить тип, основываясь на том, какую переменную мы используем.

Если noImplicitAny установлено в false , компилятор будет использовать any для типа, который он не может определить. Если мы установим для этого значение true , TypeScript сообщит об ошибке, если он не сможет определить тип. Затем у нас есть блок exclude , которым исключаем любые файлы, которые мы хотим, чтобы компилятор проигнорировал.

В дополнение к node модулям, которые содержат файлы TypeScript, мы также включили некоторые файлы из папки typings. Это связано с тем, что установлены два набора типов, поэтому мы должны игнорировать один из них.

Файл typings.json

Если мы перейдем к typings.json, мы увидим es6-shim . Это отражает типизацию, которая была добавлена в наш проект.

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

В этом случае, признак внешней среды и связанные зависимости указывают на то, что типизация файла поступает из DefinitelyTyped. DefinitelyTyped является огромным хранилищем файлов типизации для большинства популярных библиотек. В нашем файле typings.json, мы берем типизацию файла es6-shim . Число в конце показывает ID файла типизации. Типизация была установлена после установки и затем файл типизации был скопирован в нашу папку typings.

Типизация значений

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

Здесь у нас основные типы, которые мы использовали в JavaScript, но мы добавили идентификатор, который сообщает компилятору, какой тип значения был использован для переменной.

Если мы попытаемся сохранить число в переменной myName , мы получим ошибку. Это будет справедливо, если мы попытаемся сохранить неправильный тип в любой переменной. Также, мы можем использовать any , для указания на то, что для переменной может быть задан любой тип:

Мы также можем использовать void в качестве типа, как правило, в качестве типа ответа функции, которая не возвращает значение.

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

Также, мы можем записать тип массива вот так:

Потом у нас есть интерфейс, который позволяет определить форму значений в вашем коде.

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

В функции, мы определили интерфейс как форму аргумента, который мы передаем в эту функцию. Затем мы создаем объект. Последняя строка выведет наш заголовок, если мы скомпилируем и выполним этот код.

В этом интерфейсе требуется использовать только свойство title. Мы добавили другое свойство, но TypeScript это не интересует тех пор, пока в объекте есть свойство title. Если бы его не было, мы бы получили ошибку. Также заметьте, что порядок свойств не имеет значения, пока присутствует требуемое значение.

Классы

Следующее, что вам нужно понять в TypeScript это классы. В TypeScript, мы можем использовать классы для построения наших приложений объектно-ориентированных способом. Angular 2 приводит это в действие, используй классы в качестве основы фреймворка.

Вместо изучения синтаксиса фреймворка, синтаксис Angular 2 основан на TypeScript. Таким образом, вы не ограничиваете себя изучением Angular 2, так как синтаксис будет полезен при разработке за пределами Angular 2. По своей сути, класс создается следующим образом:

Любая логика, а также функция-конструктор могут быть включены в этот класс.

Мы расширяем это в Angular 2 используя декораторы, такие как @Component(<>) . Этот декоратор добавляет метаданные, которые сообщают приложению, что этот класс является компонентом Angular. Мы строим наши приложения для добавления метаданных в наши компоненты, сервисы, директивы и т.д. Все, что мы создаем для Angular 2, будет основано на классе. Мы изучим это в дальнейшем, при создании наших приложений.

Наконец, когда мы создаем наше приложение, мы запустим скрипт запуска NPM. Это запустит наше приложение для просмотра и запустит компилятор в режиме слежения. Любые изменения будут скомпилированы и отражены в предварительном просмотре. Это все основы языка TypeScript, которые вам нужно знать, чтобы начать работу с Angular 2.

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

Смотрите полный курс

В полном курсе Начинаем работать с Angular 2, вы узнаете, как создать простое веб-приложение с нуля, начиная со скаффолдинга, заканчивая конфигурацией инструментов. Вы узнаете, как использовать статически-типизированные вариации TypeScript в JavaScript для создания компонентов Angular 2, сервисов и директив. По пути вы увидите, как реализовать основы современного одностраничного приложения: включая маршрутизацию, внешний доступ к API, пользовательский ввод и проверку данных.

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

Введение в Angular

Что такое Angular. Начало работы с фреймворком

Angular представляет фреймворк от компании Google для создания клиентских приложений. Прежде всего он нацелен на разработку SPA-решений (Single Page Application), то есть одностраничных приложений. В этом плане Angular является наследником другого фреймворка AngularJS. В то же время Angular это не новая версия AngularJS, а принципиально новый фреймворк.

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

Одной из ключевых особенностей Angular является то, что он использует в качестве языка программирования TypeScript. Поэтому перед началом работы рекомендуется ознакомиться с основами данного языка, про которые можно прочитать здесь.

Но мы не ограничены языком TypeScript. При желании можем писать приложения на Angular с помощью таких языков как Dart или JavaScript. Однако TypeScript все таки является основным языком для Angular.

Последняя версия Angular — Angular 8 вышла в мае 2020 года. Официальный репозиторий фреймворка на гитхабе: https://github.com/angular/angular. Там вы можете найти сами исходные файлы, а также некоторую дополнительную информацию.

Начало работы c Angular

Для работы с Angular необходимо установить сервер Node.js и пакетный менеджер npm , если они отсутствуют на рабочей машине. Для установки можно использовать программу установки node.js. Вместе с сервером она также установит и npm. При этом особого какого-то знания для работы с NodeJS и npm не требуется.

После установки необходимых инструментов создадим простейшее приложение. Для этого определим на жестком диске папку приложения. Путь она будет называться helloapp . В этой папке создадим новый файл package.json со следующим содержимым:

Данный файл устанавливает пакеты и зависимости, которые будут использоваться проектом. В секции dependencies в основном определяются пакеты angular, которые необходимы приложению для работы. В секции devDependencies прописаны только те пакеты, которые будут использоваться для разработки. В частности, это пакеты для работы с языком typescript (так как мы будем писать код приложения на языке TypeScript), а также пакеты, необходимые для сборки приложения в один файл с помощью сборщика webpack.

Затем откроем командную строку (терминал) и перейдем в ней к папке проекта с помощью команды cd:

И затем выполним команду npm install , которая установит все необходимые модули:

После выполнения этой команды в папке проекта должна появиться подпапка node_modules , которая содержит все используемые зависимости и пакеты.

Затем создадим в папке проекта подпапку, которую назовем src — она будет содержать все исходные файлы. И далее в папке src создадим подкаталог app .

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

Компоненты представляют основные строительные блоки приложения Angular. Каждое приложение Angular имеет как минимум один компонент. Поэтому создадим в папке src/app новый файл, который назовем app.component.ts и в котором определим следующий код компонента:

В начале файла определяется директива import , которая импортирует функциональность модуля angular/core , предоставляя доступ к функции декоратора @Component .

Далее собственно идет функция-декоратор @Component , которая ассоциирует метаданные с классом компонента AppComponent. В этой функции, во-первых, определяется параметр selector или селектор css для HTML-элемента, который будет представлять компонент. Во-вторых, здесь определяется параметр template или шаблон, который указывает, как надо визуализировать компонент. В этом шаблоне задана двусторонняя привязка с помощью выражений [(ngModel)]=»name» и <> к некоторой модели name.

И в конце собственно экспортируется класс компонента AppComponent, в котором как раз определяется переменная name — в данном случае это пустая строка.

Создание модуля приложения

Приложение Angular состоит из модулей. Модульная структура позволяет легко подгружать и задействовать только те модули, которые непосредственно необходимы. И каждое приложение имеет как минимум один корневой модуль. Поэтому создадим в папке src/app новый файл, который назовем app.module.ts со следующим содержимым:

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

С помощью директив import здесь импортируется ряд нужных нам модулей. Прежде всего, это модуль NgModule. Для работы с браузером также требуется модуль BrowserModule. Так как наш компонент использует элемент input или элемент формы, то также подключаем модуль FormsModule. И далее импортируется созданный ранее компонент.

Запуск приложения

Теперь нам надо указать Angular, как запускать наше приложение. Для этого создадим в папке src (на уровень выше, чем расположены файлы app.component.ts и app.module.ts) файл main.ts со следующим содержимым:

Этот код инициализирует платформу, которая запускает приложение, и затем использует эту платформу для загрузки модуля AppModule.

Также в папке src определим еще один файл, который назовем polyfills.ts со следующим кодом:

Данный файл определяет полифилы — инструменты, которые необходимы для поддержки приложения на Angular различными браузерами.


Определение конфигурации

Поскольку для определения кода приложения применяется язык TypeScript, поэтому также создадим в корневой папке проекта новый файл tsconfig.json :

Данный файл определяет настройки для компилятора TypeScript. Опция «compilerOptions» устанавливает параметры компиляции. А опция «exclude» исключает из компиляции папку node_modules, которая содержит все загруженные пакеты.

Если мы используем TypeScript для работы с Angular, то эти два файла фактически будут присутствовать в каждом проекте. И их можно переносить из проекта в проект с минимальными изменениями. Например, в файле package.json можно будет задать какие-то другие версии пакетов, если предыдущие версии устарели. Можно будет изменить название проекта, версию. Можно подправить настройки TypeScript, но в целом общая организация будет той же.

Поскольку наше приложение будет разбито на несколько отдельных файлов, то для их сборки будем использовать популярняй сборщик webpack . Поэтому также определим в корневой папке проекта еще один файл webpack.config.js :

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

В данном случае я не буду подробно разбирать конфигурацию webpack, так как она более подробно разбирается в соответствующей теме. Отмечу только основные моменты. В секции entry определяются входные файлы для компиляции и имена сборок. В данном случае для файла «src/polyfills.ts» будет создаваться сборка «polyfills», а из файла «src/main.ts» (который в свою очередь подтягивает другие файлы приложения) будет комилироваться сборка «app».

В секции output определяется, что сборки будут находиться в каталоге public, и для них будут созданы файлы с названиями сборок. Плейсхолдер [name] будет передать название сборки, то есть polyfills или app.

В секции resolve указываются расширения, которые будут применяться к модулям в файлах typescript.

Секция module.rules определяет загрузчики файлов typescript, которые будут использоваться для сборки проекта. По умолчанию Webpack понимает только файлы javascript, поэтому для файлов ts необходимы специальные инструменты — загрузчики. Здесь для загрузки файлов typescript применяются загрузчики awesome-typescript-loader и angular2-template-loader .

Последняя часть файла — секция plugins определяет плагины — вспомогательные инструменты, которые применяются при сборке. В частности, плагин webpack.ContextReplacementPlugin позволяет управлять путями к файлам вне зависимости используем мы Windows или Linux.

Создание главной страницы

В конце определим главную страницу index.html в корневой папке проекта:

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

Далее подгружаются скомпилированные и собранные с помощью TypeScript и Webpack сборки — polyfills.js и app.js.

В итоге у нас получится следующая структура проекта:

И теперь, когда все готово, мы можем собрать проект и запустить приложение. Для этого в командной строке (терминале) перейдем к папке проекта с помощью команды cd и затем выполним команду npm run dev :

После этого в веб-браузере будет запущено приложение, и мы сможем протестировать его работу:

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

Angular2 — angular2 и coffeescript

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
  • Выбирать статус записи
  • Удалять ненужные записи

По этой ссылке доступно демо приложения. Все исходные коды приложения можно найти в 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 репозитории по ссылке.

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


angular2 нескромный вопрос

Немного о себе: обожаю coffeescript (livescript ещё больше) и люблю сам писать весь код, без фреймворков, без jquery и либ, имею в виду нечто напоминающее фреймворк, когда вся структура написана собой для себя — очень уютно выходит. Таким образом, пишу на не-модном, вне всяких реактов-емберов и прочих. То есть не судите строго за вопрос, я действительно не понимаю, просто не могу понять, привык видимо к другому, выпал из современности. Как бы многие местечки в интернете охвачены благоговением перед ангуляром, чуть ли не в ранга божества, наверняка большинство право и это нечто, что все изменит. Вот открываю quickstart, прохожу быстренько, получается ПАПКА ВЕСОМ 90МБ ЧТОБЫ ПОКАЗАТЬ ХЕЛЛО ВОРЛД, это, наверно, можно понять, хотя я этого не понимаю. То что поразило — сам хелло ворлд. Ангуляру требуется

1.5 секунды, чтобы вывести надпись на экран. Занавес, я в шоке, серьезно, сейчас я в шоке, вовсе не холивора ради пишу. Вот live пример: http://plnkr.co/edit/?p=preview, грузится так же. Почему нигде не написано, что он настолько медленный? Или это development режим, а в production будет моментально? Столько всего написано, про дом теней, про то, как клёво писать типы, исчезающие при трансляции, для себя, да и гугл компания весьма известная в кругах определенных, а сейчас я чувствую себя разочарованным и жестоко обманутым. Kill it before it lays eggs, так сказать. Это просто демо, сейчас попробую какой-нибудь проект дернуть-посмотреть, точно должен быть секрет.

И ещё одна сущая мелочь, но все таки: автоматическое обновление в браузере. Зачем его сделали и встроили по умолчанию, если вручную нажать F5 гораздо быстрее, чем ждать, пока их глючная поделка это сделает?

Зачем его сделали и встроили по умолчанию, если вручную нажать F5 гораздо быстрее, чем ждать, пока их глючная поделка это сделает?

Ты будешь ждать момента, когда весь ангуляр скомпилится, чтобы нажать F5? Ну, ок.

ПАПКА ВЕСОМ 90МБ ЧТОБЫ ПОКАЗАТЬ ХЕЛЛО ВОРЛД

Ты хэллоуворлдщик, штоле? Она будет одинаково весить как в хеллоуворде твоем, так и в нормальных проектах. Библиотеке же где-то надо находиться, как ты думаешь? Или ты распространяешь исходники проектами вместе с либами?

1.5 секунды, чтобы вывести надпись на экран.

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

Но он не компилится! Это js, js не компилится. Он интерпретируется. В браузер попадает код js, не байт код. Например, ruby тоже не компилится, rails — очень тяжелый фреймворк и в development должен реагировать на изменение каждый раз, но делает это нормально, не БЕСИТ такой перезагрузкой. Ещё пример lua с luajit, сам по себе lua не компилится и делает это быстро, а luajit компилируется во время исполнения и делает это ЧЕРТОВСКИ быстро. Что lua, что luajit, по большей части писали люди в одиночку, а над ангуляром и нодой последние лет 5 трудятся все кому не лень. И делают все, чтобы этим было невозможно пользоваться. Да, бомбануло, я надеялся открыть для себя грааль веб-разработки.

Ты будешь ждать момента, когда весь ангуляр скомпилится, чтобы нажать F5? Ну, ок.

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

Ну неужели настолько сложно сделать сколько-нибудь модульную архитектуру

HTTP2 ещё не везде и он всё ещё менее эффективен, чем бандлеры вроде webpack или rollup.

Нода тут ни при чём

Но он не компилится! Это js, js не компилится.

А ts компилится

Лол, а для чего? А мне уж было показалось, что на всех сайтах надписи выводятся. Может браузер это только побочный продукт ангуляра? Так вроде и на других платформах тоже надписи выводятся.

В целом, перед luajit не стоит задача «максимально эффективно передать клиенту код», поэтому толсто.

Или ты даже не минифицируешь код? Мне казалось, что в продакшне никто так не делает с нулевых.

Представим себе 50мб файлов, все они на ts. Они «скомпилировались», что другие сахарки делают вполне шустро, и теперь у нас 50мб ts + 40мб js, ибо кода меньше. Теперь я меняю строку в своем хеловорде. И все эти 50мб опять компиляться? Или это только один файл компилиться так долго?

luajit привел только потому что очень хороший, может и правда не к месту.

Мне казалось, что в продакшне никто так не делает с нулевых.

Как можно этого монстра пускать в продакшн, если в девелопменте показатели антирекордные? Топик про хеловорд, если есть секрет как сделать загрузку ангуляра приемлимой скорости, тогда, конечно, интересно продолжить.

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

наверняка большинство право и это нечто, что все изменит

JavaScript (programming language): Why does Angular JS 2 use typescript and not coffeescript?

a Jb d e px b hdU y q W J r e BvfCd t uhey B iiu r M a XsUp i Vgokf n g s RtX

Answer Wiki

Typescript has a few advantages over CoffeeScript.

  • It will check types.
  • It has >Especially the first 2 are important because angular projects are often bigger projects, so maintainability is important factor.

Type checking also has a secondary advantage. Because of the type extra information in the code an IDE can give you better autocompletion.

Angular JS и Angular 2+: детальное сравнение

Дата публикации: 2020-04-18

От автора: статья сравнивает главные отличия оригинального AngularJS от Angular 2+. Если вы застряли с Angular JS проектом и не уверены, стоит ли делать переход, эта статья поможет вам начать. За последние годы мы стали свидетелями невероятного роста Angular как фреймворка и платформы для разработки одностраничных приложений (SPA) и прогрессивных веб-приложений (PWA). AngularJS построен поверх идеи, что декларативное программирование должно использоваться для создания представлений. Это потребовало разделения манипуляций с DOM и бизнес-логики приложения. У такого подхода было много преимуществ.

Однако у AngularJS было много недостатков в плане производительности и того, как все устроено под капотом. Поэтому команда разработки потратила год, переписала код с нуля и выпустила Angular 1 в конце 2020. Большинство разработчиков считали, что Angular 2 отличался от оригинального AngularJS.

Давайте сравним и противопоставим AngularJS и Angular 2+.

Фреймворки в AngularJS и Angular 2

AngularJS следует традиционной архитектуре MVC, которая состоит из модели, представления и контроллера.

Контроллер: представляет собой то, как обрабатываются пользовательские взаимодействия и привязываются к модели и представлению.

Практический курс по созданию веб-приложения на Angular4

Скачайте БЕСПЛАТНЫЙ мини-курс и изучите базовые возможности JavaScript-фреймворка Angular 4 за ближайшие 3 дня

Представления: слой представления и сам UI.

Модель: абстрактное представление данных.

Некоторые разработчики считают, что AngularJS следует шаблону MVVM, в котором контроллер заменяется на модель представления. Модель представления – это JS функция, аналогичная функции контроллера. Ее особенность в том, что она синхронизирует данные между представлением и моделью. Изменения в UI элементе автоматически приходят в модель и наоборот.

Следующая схема показывает связь различных кусков AngularJS.

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

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

Из рисунка сверху видно, что компонент ограничен шаблоном. Компоненты составляются с помощью классов TypeScript, а шаблоны крепятся к ним через аннотации @Component. С помощью подсистемы вставки зависимостей Angular в компонент можно подключать сервисы. Концепция модулей в Angular резко отличается от модулей AngularJS. NgModule – это контейнер для определения функциональной единицы. NgModule может состоять из компонентов, сервисов и других функций. Модульную единицу затем можно импортировать и использовать с другими модулями.

Шаблоны в AngularJS и Angular 2

В AngularJS шаблоны пишутся на HTML. Для динамичности можно добавить AngularJS код, например, атрибуты, разметка, фильтры и элементы формы. Кроме того, поддерживается двусторонняя привязка данных, о которой говорилось ранее. Код ниже демонстрирует использование директив и двойных фигурных скобок внутри шаблона:

В Angular структура шаблонов от AngularJS была переработана, в шаблоны было добавлено много новых функций. Главное отличие было в том, что у каждого компонента был прикрепленный к нему шаблон. Все HTML элементы кроме html, body, base и script работают внутри шаблона. Помимо этого есть функции типа привязки шаблонов, интерполяции шаблонов, шаблонных утверждений, привязки свойств, привязки событий и двусторонней привязки. В шаблон также входят встроенные директивы атрибутов NgClass, NgStyle и NgModel, а также встроенные структурные директивы NgIf, NgForOf, NgSwitch.

Вставка зависимостей в AngularJS и Angular 2

Вставка зависимостей – это шаблон проектирования, который решает зависимости и вставляет их в компоненты, когда они необходимы. Это позволяет не забивать зависимости статично в компонент. AngularJS обладает подсистемой вставки, которая создает компоненты, вставляет зависимости и резолвит список всех зависимостей. Следующие компоненты можно вставить по желанию:

Практический курс по созданию веб-приложения на Angular4

Скачайте БЕСПЛАТНЫЙ мини-курс и изучите базовые возможности JavaScript-фреймворка Angular 4 за ближайшие 3 дня

Сервисы, директивы и фильтры можно вставить с помощью метода factory. Пример метода factory. Метод factory регистрируется с модулем myModule:

Подход остался тем же, но в Angular система вставки зависимостей обновлена и отличается от старого шаблона DI. Вставка зависимостей Angular управляется массивом @NgModule, который состоит из providers и declarations. Массив declarations – это пространство объявления компонентов и директив. Зависимости и сервисы регистрируются в массиве providers.

Представьте, у вас есть сервис ContactlistService, вытягивающий список контактов и предоставляющий его в компонент ContactList. ContactlistService сперва необходимо зарегистрировать в app.module.ts в массиве providers. Далее нужно вставить сервис в компонент:

Мы говорим Angular вставить сервис в конструктор компонента.

JavaScript или TypeScript

AngularJS – это чистый JS фреймворк, а модули в AngularJS представляют собой старые, простые JS объекты. Это сильно облегчает процесс создания проекта. Любой разработчик с базовым пониманием JS может начать работу с фреймворком. Благодаря этому, Angular 1.0 очень легко поддается изучению по сравнению с другими фреймворками.

Angular 2+ представил TypeScript как язык по умолчанию для создания приложений. TypeScript – это синтаксическое надмножество JS, которое компилируется обратно в чистый JS. Команда Angular выбрала TypeScript, а не JS из-за функции аннотации типов, которая позволяет проводить необязательные проверки статичных типов. Проверка типов может отлавливать ошибки компиляции, которые могли пробраться в код. В противном случае вы бы их не заметили. Ваш JS код становится более предсказуемым.

Помимо этого TypeScript популярен за свои классы, интерфейсы и декораторы (декораторы классов, декораторы свойств и декораторы параметров). Angular использует классы TypeScript для определения компонентов. @Component – популярный пример того, как декораторы класса используются для прикрепления метаданных в компонент. Обычно это включает в себя детали конфигурации компонентов, такие как тег селектора шаблона, массивы templateUrl и providers, чтобы вы могли вставлять любую связанную зависимость в компонент:

Поддержка инструментов для AngularJS и Angular 2

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

У AngularJS нет официального CLI, но было много сторонних генераторов и инструментов. Среди разработчиков были популярны IDE WebStorm и Aptana. Если вы как я, вы можете настроить нормальный текстовый редактор типа Submlime Text editor и добавить в него правильные плагины. В AngularJS есть расширение ng-inspector для браузера для отладки и тестирования. Структура AngularJS с легкостью позволяла импортировать сторонние модули. Все популярные ng модули можно найти на ngmodules.org, open-source проекте для хранения модулей AngularJS.

По сравнению с AngularJS у Angular поддержка инструментов лучше. Есть официальный CLI, позволяющий инициализировать новые проекты, обслуживать их и строить оптимизированные пакеты на продакшен. Более подробно можете почитать о Angular CLI на GitHub. Вместо JS Angular использует TypeScript, поэтому в качестве IDE поддерживается Visual Studio. Это не все. Есть много плагинов для IDE и независимых инструментов, помогающих автоматизировать и ускорить определенные аспекты цикла разработки. Augury для отладки, NgRev для анализа кода, Codelyzer для валидации кода и т.д. Довольно полезные инструменты.

Заключение


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

В этой статье мы обсудили ТОП-5 различий AngularJS и Angular 2. За исключением структуры шаблонов и вставки зависимостей почти все другие функции были обновлены. Много популярных функций Angular 1.0, таких как контроллеры, область видимости, директивы, определение модулей и т.д. были заменены на другие. Был изменен основной язык и структура.

Автор: Manjunath M

Редакция: Команда webformyself.

Практический курс по созданию веб-приложения на Angular4

Скачайте БЕСПЛАТНЫЙ мини-курс и изучите базовые возможности JavaScript-фреймворка Angular 4 за ближайшие 3 дня

Angular 4 с Нуля до Профи

Angular 4 — полное руководство для современной веб-разработки

Angular 2 просто ужасен

Мы используем Angular 2 в наших веб-интерфейсах. Я не принимал участия в этом решении, так как пришёл работать в этот проект относительно поздно. Статья не претендует на исчерпывающий обзор фреймворка, скорее это совокупность наблюдений после использования его в течении двух недель. Я не утверждаю, что использование его в течении двух недель делает меня экспертом, и приветствую любые корректировки, но считаю что использование Angular 2 это одна из самых больших ошибок в нашем проекте.

Ненадёжная основа

Стабильная версия Angular 2 основана на экспериментальных особенностях языка (TypeScript decorators, based on a Stage 1 TC39 draft proposal) и библиотеках находящихся в бете версии (Rx.js 5.0). Позвольте повториться, что от фреймворка требуется больше стабильности, чем от его зависимостей и языка с помощью которого он разработан. Это абсолютное бемзумство. Angular 2 не должен называть себя стабильным, пока его основные зависимости не будут стабильными. Создание приложений с помощью него, это как строительство карточного домика. Что случиться, если семантика декораторов измениться или вообще пропадёт из языка?

Фатальный недостаток (Not Invented Here)

Angular 2 — это фреймворк в прямом смысле этого слова. Он использует собственную систему загрузки модулей (потому что возможностей JavaScript не хватает, не так ли?), пытается абстрагироваться от всей браузерной платформы, и даже поставляется с полноценным HTML-парсером и санитайзером. Он даже разговаривает на собственном языке — структурные директивы, трубы (pipes), декларации, модули, инжекторы, сервисы, инкапсуляция представлений, декораторы.

Становиться сложнее изучать фреймворк. Даже те кто уже знаком с API браузера и реактивными фреймворками, должен переучиваться чтобы понять как это делается в Angular. Трубы (pipes), например, практически не отличаются от концепции Unix pipes или фильтров которые вы могли видеть традиционных шаблонизаторах таких как Twig. Другой пример: HTTP клиент в Angular возвращает Observables вместо Promises, заставляя нас выучить не только другую асинхронную библиотеку, но ещё и другую парадигму.

Это усугубляется тем, что несмотря на утверждения в документации, Observables не даёт ощутимых улучшений в сравнении с Promises, при использовании AJAX запросов.

Многие методы Rx.js проиллюстрированы с помощью потоков, как этот. По смыслу это подходит для данных, которые на самом деле являются потоками, но избыточно для запросов состоящих из одного значения.[/caption]

AJAX запросы являются сингулярными, и запущенные методы такие как Observable.prototype.map не имеют никакого смысла, когда есть только одно значение. Promises с другой стороны представляют собой значение, которые ещё предстоит выполнить, это именно то что даёт нам HTTP запрос. Я потратил несколько часов чтобы заставить Observables работать, перед чем начал использовать Observable.prototype.toPromise чтобы преобразовать Observable назад к Promises и просто использовать Promise.all , который работает намного лучше чем то что предлагает Rx.js.

Поспешная абстракция

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

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

Он делает это путём абстрагирования от различных частей API браузера. Angular заменяет DOM с помощью собственного нелепо модифицированного HTML, историю браузера и Location API с помощью собственной маршрутизации и сервиса местоположения, а XHR и веб-сокеты с помощью собственного HTTP клиента. К сожалению, это смехотворно маленькое подмножество API, которое может понадобиться современному приложению. В любое время вам может понадобиться что-то простое, например LocalStorage, геолокация, push-уведомления, или даже простой полифилл по разному поддерживаемый браузерами для input type=»date» и вы тут же нарушите своё обещание о том, что ваше приложение кросс-платформенное.

Что ещё более важно, это то что в большинстве случаев эта абстракция просто не нужна. Некоторые вещи из Angular platform API — это просто тонкие обёртки вокруг API браузера, которые не делают ничего полезного, а только усложняют его использование. Геолокация и HTTP клиент — два хороших этому примера.

Цитата выше намекает на изучение одного фреймворка для разработки приложений под все платформы, но обратная сторона изучения этого фреймворка заключается в том, что вы не сможете использовать полученные знания в другом месте. Изучите основы Fetch API и вы сможете использовать его в любое время при разработке веб-приложений. Изучите HTTP клиент из Angular и эти знания будут бесполезны за пределами вселенной Angular.

HTML minus

Angular утверждает, что HTML Plus — это как HTML, но только лучше. Это неправда.

Во-первых, Angular HTML это не HTML. HTML атрибуты не чувствительны к регистру, а у Angular’а чувствительны. Это может показаться небольшой разницей, но это означает что любой инструмент разработанный с поддержкой HTML кода, не может поддерживать его Angular версию. Например в WebStorm автодополнение, ожидает что вы напишете ngif, но не как не ngIf. Они эквивалентны в HTML, но не в Angular HTML.

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

Примеры приведённые выше эквивалентны, но если вы смешаете синтаксис, следующий пример просто не будет работать, без всяких предупреждений:

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

который вообще ничего не отображает. Vue использует для этого одну директиву v-if и обычные HTML-теги работают так как они должны работать.

ngFor в Angular использует синтаксис микроразметки. Я никогда не видел шаблонизаторов которым нужен DSL для циклов.

let вводит в заблуждение — потому что на самом деле вы не можете делать присваивание в этих выражениях, что собственно заставляет задумываться, а зачем вообще всё это нужно? Синтаксис Vue, для примера, намного проще и разумнее:

Pipe’ы в Angular (все остальные фреймворки называют их «фильтры») могут принимать параметры. Но для нескольких значений в качестве разделителя используется двоеточие, а не запятая как это сделано почти в каждом шаблонизаторе, который я использовал. Зачем? Понятия не имею.

Все приведённые выше проблемы раздражают, но терпимы. Заключительная проблема, хотя это проблема проектирования, лежит в основе философии Angular’а. Angular пытался переместить большую часть прикладной логики в шаблоны — логический поток, событие и связывание свойств, директивы, ссылки в язык разметки HTML. Я покажу вам кусок нашего кода, который говорит о том, что это было плохой идеей.

Чтобы быть справедливым, иметь логику в шаблонах — это не обязательно плохо. Я не защищаю пуританский подход как в Mustache и нахожу логику в большинстве шаблонизаторов приемлемой. Проблема связана с шаблонами в Angular, которые позволяют и даже в некоторой степени поощряют связывание всего и вся с компонентами. Это способствует медленному наращиванию слоёв из излучателей событий и входных данных, пока вы не получите результат, который только что увидели выше, вместо спланированной модели данных для приложения. Сейчас в большинстве наших компонентов бардак из обработчиков событий, излучателей и свойств с крайне плохим разделением. И всякий раз когда нам нужно повторно использовать компонент, как правило мы копируем и вставляем код.

Ненужное многословность

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

Для создания компонента в Angular, нужно создать отдельные JS, CSS и HTML файлы. В зависимости от настроек, JavaScript может быть скомпилирован из TypeScript, а CSS может быть скомпилирован из SCSS или LESS, так что это 5 отдельных файлов для одного компонента. В связи с большим количеством файлов, вам нужно создавать отдельную папку для компонента. Сам компонент представляет собой класс с декоратором @Component , который объявляет метаданные компонентов такие как стили, шаблон и селектор, чтобы компонент можно было повторно использовать в других местах. После этого происходит внедрение зависимостей через конструктор, и не забудьте объявить интерфейсы жизненного цикла компонента. В заключении вам нужно зарегистрировать компонент в файле модуля приложения. Очень много работы, ради одного компонента.

Сравните этот подход с единственным файлом компонента в Vue. Для Vue, разметка, стили и логика объявляются в одном единственном файле. Компонент выражается как простой JavaScript объект. Есть очень маленький ритуал, который позволяет легко создавать новые компоненты.

Одиночные файлы компонентов возможны и в Angular, но вам нужно объявлять разметку и стили в TypeScript, а он (насколько я знаю) не совместим с препроцессорами, такими как SCSS.

Существенная разница? Я думаю, да. В нашем Angular приложении 21 компонент, в тоже время у нашего Vue приложения их более 30, хотя последнее намного проще. Vue компоненты маленькие и простые, в то время как Angular компоненты неудержимо растут, потому что проще добавлять некоторые вещи в один компонент, чем дробить их на отдельные.

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

Это может быть связано с конкретно нашей настройкой, но Angular 2 кажется очень тяжёлым. Приложение построенное на Vue, которое я разрабатывал для себя, перестраивается в одно мгновение. Во время разработки, пока я переключаю взгляд с рабочего пространства на браузер, страница уже перезагружена и отображена. Нашему Angular 2 приложению требуется несколько секунд чтобы перестроиться и отобразиться. Это может показаться недолго, но не забывайте что любые изменения в исходном коде вызывают перезагрузку, поэтому это происходит сотни раз в день.

В Vue из коробки есть модуль горячей перезагрузки стилей в режиме разработки, в то время как в Angular ничего этого нет, что тоже замедляет работу. Хоть и есть возможность настроить модуль горячей перезагрузки в Angular 2, Vue уже настроен по умолчанию.

Точно также, если Vue приложение поддерживает отображение шаблона перед компиляцией (ahead-of-time (AoT)) из коробки, то в Angular 2 всё это нужно настраивать и подключать сторонние зависимости. Подключение зависимостей наиболее важно потому что, для настройки в приложении поддержки AoT компиляции, всё тоже самое требуется и для зависимостей. Также это способствует увеличению размера. Изначальный размер нашего приложения 1MB.

Один мегабайт. Это размер приложения с единственным вендором и файлами полифиллов. Кроме того это размер всего JS использованного в нашем приложении. Он включает в себя 600kb использования Three.js и OSM Building библиотеку. 0.js содержит Three.js, а 1.js содержит OSMB.js. Это очень большие JS библиотеки спроектированные для 3D отображения в браузере, и даже когда они обе включены в наше приложение, оно меньше чем при использовании Angular.

Vue на собственной странице сравнения фреймворков отмечает, что «Hello World» в Angular 2 приложении может быть таким же лёгким, и весить всего 50 килобайт после встряхивания дерева (tree shaking). Тем не менее помните, что такой номер проходит только после удаление всех компонентов, которые не нужны для сборки, в то время как Vue 2.0 весит 23 килобайта из коробки. Другими словами, 23 килобайта это максимальный размер для Vue, а 50 килобайт это лишь минимальный размер для Angular.

Проталкиваем Java назад в JavaScript

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

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

По умолчанию, даже если нам придётся проверять каждый компонент всякий раз когда вызывается событие, Angular очень быстрый. Он может выполнить сотни тысяч проверок в течении пары миллисекунд. В основном это объясняется тем, что Angular генерирует код для VM.

Разумеется я вас не знаю, но это смелое заявление, звучит дико. Angular обрабатывается браузерным JavaScript движком в качестве VM, но это не совсем так, как делает это Java. Что это означает в дополнении к трассировки стека для трёх длинных страниц и бесполезному профайлеру, дак это то что производительность полностью во власти движка. Есть только одна JVM, а у JavaScript есть полтора десятка различных движков, с разными профилями производительности. Я могу только предполагать, что код сгенерированный Angular будет «VM friendly» для всех остальных. Многообещающе.

На этом сходства с Java не заканчиваются. Angular — это не JavaScript фреймворк, а это TypeScript фреймворк. TypeScript выглядит безопасным потому что он строго типизированный. Это отчасти верно, но TypeScript страдает от той же проблемы что и Java — он не может хранить ссылку на null. Даже хуже, потому что у TypeScript нет времени выполнения для компонентов и он не выбрасывает предупреждения во многих не безопасных случаях, язык предлагает только иллюзию безопасности. Для примера это совершенно допустимый код написанный на TypeScript, который не вызывает никаких предупреждений.

Ужасная документация

У Angular 2 наихудшая документация из всех крупных фреймворков, которые я когда либо видел. Она не аккуратная, неполная и плохо написанная. Для начинающих, Angular — это JavaScript фреймворк, у которого нет документации на JavaScript. На странице «Quickstart» говориться следующее:

Не смотря на то, что в разделе «Getting started» приводятся примеры на TypeScript, вы можете писать Angular приложения на JavaScript или Dart. Используйте переключатель языка программирования в левой навигационной панели, для того чтобы переключить язык используемый в этом руководстве.

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

Большая часть документации была написана для TypeScript разработчиков и ещё не была переведена на JavaScript. Пожалуйста оставайтесь с нами. Между тем мы будем предоставлять ссылки на TypeScript главы, где документация по JavaScript не доступна.

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

Документация плохо организована. Авторы разделили её на три секции «Guide», «Advanced» и «Cookbook», но разграничения довольно таки произвольны. Например, руководства по формам и синтаксису шаблонов находится в секции Guide, а руководства по маршрутизации и навигации в секции Advanced. Ahead-of-Time компиляция почему то является разделов в Cookbook, также как и валидация форм. Ни один из приведённых только что примеров не имеет никакого смысла, а что ещё хуже, открытие второго уровня навигации полностью перезагружает страницу, что делает процесс поиска информации мучительно долгим.

Страницы в руководстве пронумерованы, но эти цифры ничего не значат. «Forms» находится перед «Template Syntax», даже при том что синтаксис двустороннего связывания данных, используемый в формах, описывается только в синтаксисе шаблонов.

Отдельные руководства сами по себе плохо написаны. Вот абзац из руководства по Pipe’ам:

Давайте напишем ещё один грязный pipe, который делает HTTP запрос к серверу. Как правило это ужасная идея. Вероятно, это ужасная идея независимо от того что мы делаем. Мы всё равно продвигаемся вперёд чтобы поставить точку. Помните что грязные pipe’ы вызываются каждые несколько микросекунд. Если мы не будем осторожны, то этот pipe покарает сервер запросами.

Стиль написания совершенно невыносим. Только первое и последнее предложение могут рассказать нам что-то полезно, но и они содержат большие технические ошибки — автор, вероятно имел в виду миллисекунды, а не микросекунды, величины которых различаются на три порядка. Опечатки есть по всюду (Прим. переводчика: Не стал переводить, чтобы было видно в каких местах опечатки):

The component doesn’t have to subscribe to the async data source, it doesn’t extract the resolved values and expose them for binding, and the component doesn’t have to unsubscribe when it is destroyed (a potentsource of memory leaks).

Despite the two bindings and what we know to be frequent pipe calls, the nework tab in the browser developer tools confirms that there is only one request for the file.

Вся документация читается так, как-будто написана и закодирована стажёром, которую недостаточно заплатили, чтобы позаботился о ней.

Будущее веб-разработки!?


Когда я знакомился с Angular 2, я надеялся что он будет элегантным фреймворком, который находится на одном уровне с такими проектами как Laravel или Django, и сделает разработку веб-интерфейсов лёгкой и приятной. Но всё что я увидел, это то что он является нестабильных, раздутым, слишком усложнённым фреймворком, который много что обещает, но мало что делает.

Angular 2+

Более подробно об Angular вы можете узнать на сайте coldfox.ru (Angular). На coldfox.ru присутствует целый раздел посвященный непосредственно Angular.

Концепция Angular

  • export — ‘раскрывает’ некоторые компоненты/директивы/фильтры другим модулям приложения. Без этого компоненты/директивы/фильтры определенные в модуле доступны лишь в этом модуле.
  • imports импортрируем сторонние модули (необходимые для работы), тем самым делая экспортированные объявления (exported declarations) других модулей доступными в текущем модуле, например, AutoCompleteModule из primeng
  • declarations — указываем компоненты, директивы и pipes , которые принадлежат модулю. Тем самым делаем эти директивы, включая компоненты и фильтры, из текущего модуля доступными для других директив в текущем модуле. Селекторы директив, компонентов или фильтров сопостовляются только с HTML, если они объявлены или импортированы (declared or imported)
  • providers — делают сервисы и значения доступными для DI. Они добавляются в корневой scope и они вводятся (injected) в другие сервисы или директивы, которые имеют их как зависимости.
  • bootstrap — здесь мы указываем то, что нужно запустить при старте приложения.

@angular/core

Возможности import рассмотрим на примере:

Модули

Angular 2 состоит из модулей. Приложение на angular 2 также является модулем.

Мы можем создавать свои модули для объединения сущностей по типу. В будущем этом поспособствует скорости загрузки приложения, например, с помощью Lazy Loading.

Все модули подключаются в массив imports :

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

Вот собственно говоря пример стороннего модуля (связка по типу фразы/Phrase):

Модуль для роутинга (пример)

Регистрируем директиву (etc.) для всего приложения

Допустим, у нас есть директива, но задекларированная в общем модуле, если мы добавим ее (посредством declaration) в дочерний модуль, то js выдаст ошибку с примерно таким описанием: нельзя задекларировать директиву дважды. Отсюда возникает вопрос — как обойти эту проблему?

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

LAZY LOADING

Декомпозиция модулей (разбиение на модули) нужна в том числе для Lazy Loading (ленивая загрузка) — данную особенность предоставляют модули. Обычно приложение загружает весь js со всеми модулями, но зачем нам загружать все страницы, к примеру, если тот же юзер на второстепенные страницы может не перейти? Незачем. Поэтому мы можем вынести второстепенные страницы в отдельные модули и загружать их по необходимости.

Вот и рассмотрим на примере роутинга, то есть подключение модуелей с Lazy Loading по мере необходимости. Как видите мы подключаем модуль указав путь, а не через import , ибо import загрузит модуль сразу, а нам это не надо, также удалите import < BooksModule >в app.module.ts . Мы не будем использовать import , чтобы не webpack сразу не подключил наш файл в приложение.

loadChildren — значением данного свойства является строка, чтобы webpack ничего заранее не загрузил.

Теперь при переходе на страницу books в консоли вы сможете увидеть подгружаемый chank.

Отметьте, что для Guard вместо canActivate: [AuthGuardAdmin] нужно писать canLoad: [AuthGuardAdmin]

Компоненты

Компоненты отвечают за внешний вид и за взаимодействие с пользователем.

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

Компоненты представляют из себя часть пользовательского интерфейса.

Идея компонентов состоит в том, чтобы разделить пользовательские интерфейсы на составные части.

При создании компонентов имена тегов в свойстве selector должны подчиняться следующим правилам:

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

Директивы

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

Структурная директива

Структурная директива (на это указывает * ), которая меняет DOM — (например, ngFor — добавляет элементы)

  • *ngIf — удаляет или создает часть дерева DOM на основании выражения.
  • *ngFor

Атрибутные директивы

Атрибутные директивы (на это указывает [] ) предназначены для изменения внешнего вида или поведения элементов (они не создают и не удаляют элементы, например, [ngClass] )

ngSwitch

ngSwitch — директива используется для того, чтобы отобразить один элемент (включая дочерние) из набора возможных элементов. При использовании директив ngSwitchCase и ngSwitchDefault обязательно нужно использовать ( * ). Можно использовать любой тип данных при установке значения в ngSwitchCase

Свойство selector

Свойство selector позволяет определить к какому DOM-элементу или компоненту применить директиву. Свойство selector :

Пользовательские директивы

Импортируем класс Directive

@HostListener — с помощью данного декоратора можно подключить обработчики событий, возникающие во вмещающем компоненте.

Выходные свойства и директивы

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

При это, как видите, в классе директивы my-attr мы работаем со множеством входных свойств, которые необходимы для реализации логики директивы.

Кастомная директива: renderer, @HostBinding, передача параметров

Использование renderer

Данный подход не совсем правильный, так как angular может работать не только в браузере (например, мобил. приложения), поэтому мы не всегда имеем доступ к DOM-дереву.

Поэтому в angular есть специальный интерфейс, котор. называется renderer (см. пример выше)

@HostBinding (привязка свойств)

Декоратор @HostBinding позволяет привязать, например, какое либо свойство (например, border ). Данная связка будет положена в переменную, см. пример выше, через которую мы сможем менять это свойство.

@HostListener (привязка событий)

см. пример выше для события mouseenter .

Передача параметров

Параметр в директиву можно передать через обычное входящее свойство: [hoverColor] = «‘red'» (см. пример выше). Или как значение непосредственно самой директивы.

Создание двусторонней привязки для директивы

Да, директивы поддерживают пользовательскую привязку [()] . Функциональность двусторонней привязки опирается на соглашение об именах.

Привязка осуществляется на базе входного свойства и метода ngOnChanges — это из модели в директиву. И через слушателя события input .

Директива ngSwitch

Директива ngSwitch появилась в 4-м angular. Директиву ngSwitch удобно использовать, например, для табов.


Фильтры (pipes)

Фильтры — так называемые ‘помощники’, которые форматируют вывод данных в шаблонах в зависимости от наших потребностей.

  • uppercase
  • lowercase
  • number
  • percent
  • currency
  • slice
  • date
  • json
  • replace
  • i18nPlural — число по объекту в строку
  • i18nSelect — анализирует строку
  • async — наблюдает за асинхронными данными

Пользовательские фильтры

Импортируем декоратор pipe и интерфейс PipeTransform

Обязательный метод класса transform имеет два параметра:

  • 1 — входные данные
  • 2 — параметры для настройки фильтра

И возвращает преобразованные данные

Декоратор

Декоратор — особенность, появившаяся в ES7, и затем добавленная в TypeScript, позволяющая добавлять метаданные в классы.

Все декораторы узнаются по префиксу @

Простейший пример декоратора:

Декоратор @ViewChild

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

Декоратор @ViewChildren

Декоратор @ViewChildren позволяет получить доступ сразу ко всем компонентам. В примере ниже получаем все дочерние компонеты (реализованы см. выше) в родительском компоненте.

Чтобы получить из множества дочерних компонентов какой-то определенный можно задать template reference variable ( #heroInput ).

Декоратор @ViewContent

@ViewChildren и @ViewChild работают лишь с теми компонентами, которые нахлдятся непосредственно в шаблоне. Если же мы получили компонент через ng-content то, чтобы получить к нему доступ нужно воспользоваться декоратором @ViewContent .

Template Reference Variable

Выше мы уже затронули template reference variable. Давайте расмотрим это понятие более подробно.

Template Reference Variable — ссылка на DOM элемент или директиву в шаблоне. К переменной можно обратиться в любой части шаблона, в котором она объявлена.

Есть два способа объявления переменной:

  • префикс # , например #varNameThere
  • префикс ref- , например, ref-varNameThere

ng-content

Рассмотрим использование ng-content на примере.

Шаблон компонента потомока:

Вмещающий компонент родитель:

Типы привязки

Типы привязки могут быть сгруппированы в три категории в зависимости от потока данных: от source-to-view, от view-to-source, и в двунаправленной последовательности: view-to-source-to-view:

Направление данных Синтаксис Тип
Однонаправленный от источника данных к view Interpolation
Property
Attribute
Class
Style
Однонаправленный от view к источнику с данными Event
Двунаправленный Two-way

Атрибуты

[] Входное свойство

[] — сообщают феймворку, что атрибут является входным свойством.

Если требуется связать свойство с переменной компонента, то: [my_prop]=»<>» .

Декортатор Input

Декортатор Input указывают, какие свойства вы можете установить на компоненте.

В самом todo-item импортируем декортатор Input (им помечаются входные данные) —

Используем в компоненте:

При удалении нужно передать данные от потомка родителю ( (delete)=»delete($event)» ), один из способов — это события (можно подписаться на события пользовательских компонентов).

() Выходное свойство

() — сообщают феймворку, что атрибут является выходным свойством, запускающее подключенный к нему обработчик событий.

Значение можно определить явно — для этого значение следует заключить в одинарных кавычках внутри двойных кавычках.

Двунаправленное связывание ( [(. )] )

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

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

Для этих целей у ангуляра есть специальное двунаправленное связывание: [(x)] .

У свойства [(x)] будет соответствующее событие xChange .

Декоратор Output (EventEmitter)

В дочернем импортируем декоратор Output (им помечаются выходные данные)

Или Output идентифицируют события, которые компонент может инициировать для отправки информации по иерархии родительскому элементу.

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

Класс EventEmitter предназначен для объектов способных генерировать события. Также эти объекты предоставляют интерфейс для подписки на эти события.

Пример использования декоратора Output

От ребенка ( todo-item.component ) родителю ( todo-list.component.html )

Привязка данных: Шаблонные теги

Шаблонные теги (интерполяция) — один из видов привязки данных

Привязка данных: через свойство DOM-элемента

Привязка события (event binding)

Формы

Для работы с формами используется модуль:

Благодаря модулю FormsModule мы можем использовать ngModel для привязки к свойству, ngSubmit :

Директива NgForm

Директива NgForm — отслеживает состояние всех элементов формы.

Как отмечалось выше, конструкция #todoForm=»ngForm» поместит в переменную todoForm объект формы. Но в качестве альтернативы вы можете воспользоваться декоратором @ViewChild , чтобы получить ссылку на форму непосредственно в компоненте:

Директива NgModelGroup в TD подходе


Создает и связывает FormGroup экземпляр с DOM элементом. Иначе говоря позволяет объединять контролы в группу в TD (template driven) подходе.

К этому блоку можно также задать local reference #user=»ngModelGroup» и проверять валидацию (выводить сообщения) как у обычного контрола.

Директива NgModel

Директива NgModel создает экземпляр FormControl из модели и связывает его с элементом формы.

В формах оставлена двусторонняя привяка при помощи директивы NgModel .

[(ngModel)] — указывает на строковое свойство компонента, обеспечит обновление модели в обоих направлениях (иначе говоря, двусторонняя привязка данных).

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

Где #title = «ngModel» это reference на angular control.

Валидация и NgModel

Валидация при помощи valueChanges и statusChanges

Более реактивную валидацию можно реализовать при помощи valueChanges и statusChanges .

Они оба возвращают Observable :

Объект FormControl

FormControl один из трех фундоментальных строительных блоков форма Angular, помимо FormGroup и FormArray .

Чтобы сообщить Angular о том, что input связан с name FormControl в классе (reactive-forms#create-the-template), вам потребуется в шаблоне воспользоваться директивой formControl , в angular 2 — ngControl .

  • Первый аргумент — значение
  • Второй аргумент — функция-валидатор

FormGroup

FormBuilder

Класс FormBuilder обеспечиват большую гибкость при создании сложных форм внутри контроллера компонента.

How Angular is reinventing itself with version 2 and TypeScript

AngularJS began to gain serious traction in 2012, attracting significant popularity as it cut through the noise in the crowded frontend framework landscape. Angular enthusiasm was quick to wane, however, as the framework fell victim to the trough of disillusionment that sits on the other side of the hype cycle. React is the new darling, perched on the peak of inflated expectations where it will likely be displaced by some shiny thing that comes along in the future.

The original AngularJS offered some good ideas, but it wasn’t a very good framework in practice. Its successor, Angular 2, addresses many shortcomings while retaining many of the strengths that made the original framework popular. With the benefit of a clean break, the developers behind Angular 2 were able to exorcise many of the framework’s most pernicious demons.

Users can finally put to rest the shambling horde of gratuitous $scope.$apply invocations that seemingly haunt every dark corner of AngularJS apps. And you can put a sharpened stake through the arcane parameter scraping hacks in the dependency injection system that used to bite during minification and other post-processing operations.

In short, almost everything is less awful. You’re still stuck with much of the distressingly esoteric terminology that the Angular developers afflicted upon the world, but I think many are willing to live with the lingering horror of ugly phrases like “directive transclusion” as long as nobody will never again have to degrade themselves by typing $scope.$apply .

Existing Angular enthusiasts will find that the things they know and love still endure in the framework’s new iteration. It is highly conducive to automated testing, you can compose your application with custom directives, and the data binding system supports one-way and two-way bindings against conventional JavaScript objects.

Angular 2 is still under heavy development, but I recently decided to take an early look. I used the latest Angular 2 beta to build a simple realtime chat application, paired with a backend built on Node.js and RethinkDB. I wrote the demo application in TypeScript, a language that pairs JavaScript with a flexible type system. I used TypeScript for both the Node.js backend and the Angular 2 frontend.

TypeScript

TypeScript allows the developer to annotate variables and function parameters with type declarations, which external tools can use to support features like static type checking and autocompletion. It is designed as a superset of JavaScript, adding new features without compromising the expected behavior of the original language. It supports a w >class keyword and arrow functions. Like CoffeeScript, TypeScript code transpiles to browser-friendly JavaScript, which means that you can use it to build frontend web applications.

TypeScript support is optional in Angular 2, but adopters will quickly find that it’s a great match for the framework. The Angular developers built the new version of the framework to take advantage of TypeScript’s strengths. They even collaborated with TypeScript’s core team at Microsoft to foster new language features that address specific Angular needs.

When building an Angular 2 application with TypeScript, you define each new directive in its own class. TypeScript decorators provide a convenient way to specify component metadata and properties, including the custom tag name and the list of external directives that you want the dependency injection system to make available for use.

TypeScript’s approach to type checking is unobtrusive and conducive to incremental adoption. You can choose to apply type declarations wherever you want, and leave them out when you don’t need them. You can also easily mix conventional ES6 code and TypeScript code in the same project without worrying about the boundaries or how the type system will affect interoperability.

In addition to simplifying Angular component definitions, TypeScript can offer a measure of additional safety and convenience throughout your project. When you work with arbitrary JSON data from a NoSQL database or a REST API, for example, you can use a TypeScript interface to formalize property access and avoid errors.

Consider a case where you are building a game and you have information about user scores. You could define the following TypeScript interface to describe the structure of the JSON objects that you store in your database:

When you fetch the associated records from your database, you can use a simple Array type declaration to indicate that you are retrieving an array of objects that conform with the interface. In the following example, written in Node.js on the backend, I retrieve the documents from RethinkDB and iterate over them:

If you write code that accesses an undefined property, the TypeScript compiler will save you from shooting yourself in the foot. It will also intelligently offer autocompletion whenever you start accessing a property on a record in the users array.

In the code above, you will also notice that I was able to use ES7 async and await keywords, which TypeScript supports experimentally. You can use async and await to flatten and simplify code that expresses the flow of asynchronous operations. Out of the box, you can await any operation that returns a promise. Another major advantage of using await instead of .then is that it works seamlessly with conventional JavaScript exception handling.

You can share interface definitions, like the UserRecord example above, between frontend and backend code–using it on both sides of the stack. If you use a REST API or WebSockets to pass the underlying JSON objects to the frontend, you still get the same property access checks and basic type safety anywhere you use a type assertion to apply the interface.

It’s important to keep in mind that interface definitions and other features of the TypeScript type system only prov >UserRecord definition, for example, it doesn’t perform any checks at runtime to ensure that the objects you receive actually match the structure that you define.

To get the full advantages of TypeScript, you will likely want to use a development environment that supports TypeScript integration. I built my demo application in GitHub’s open source Atom editor, with the atom-typescript plugin. It automatically compiles your TypeScript code into JavaScript when you save a file, exposing any errors that it finds along the way. It also has highlighting, autocompletion, symbol browsing, rename refactoring, and a number of other features.

Other editors that support TypeScript development include Visual Studio Code and WebStorm. You can also use command-line tools, though that doesn’t provide quite the same degree of workflow integration.

Angular 2

Angular 2 applications are built with components, discrete units of functionality that developers compose to achieve the desired result. Each component is an object that includes template markup, metadata, and supporting functions. When you build an Angular 2 application with Typescript, each component is a >Component decorator, you can annotate the class definition with relevant component metadata like the component’s tag name, exposed properties, and emitted events. The following code example, a complete component from my chat demo, displays a single message sent by a user:

As you can see, the entire component is defined with a >ChatMessage . The selector field in the @Component decorator indicates that chat-message is the name of the tag, which you can use in template markup when you want to create an instance of the component. The properties field tells the component how to expose >ChatMessage component, it will look a bit like this:

You use the selector name to create the component instance, and then you can use data binding to attach the value of a variable to the message attribute. The square brackets around the attribute are used to signify that the data binding is one-directional instead of a two-way binding.

The @View decorator typically contains the component’s template and template metadata. In this particular case, I used a multiline string to embed the template markup directly. When the markup is more complicated, however, you would typically just provide the path of an external HTML file.

The @View decorator is also used for dependency injection. Like its predecessor, Angular 2 uses dependency injection to make a given unit of functionality available in a particular context. When a component uses other components in its markup, you add directives property to the @View decorator with an array of the components that you want to inject.

In my chat demo’s top-level application component, for example, I use three of my own custom components in addition to several from Angular’s standard libraries. In the following source code, you can see how I use the directives property to inject the imported components:

The NgSwitch component lets me conditionally choose between showing the login form or a list of messages depending on whether the user has logged in. The NgFor component lets me display a series of messages bound to an array. You can see that I’m using it on my own custom ChatMessage component, which encapsulates the logic for displaying a message.

When the user logs in, the application use the HTML5 fetch API to retrieve the initial messages. It also connects to Socket.io so that it can receive updates. When new messages arrive, it appends them to the array where the message list is bound. There’s also an onMessage event handler that fires when the user sends a message from the ChatInput component. It uses a POST request to push the user’s new message to the server.

Angular 2 is clearly a lot more intuitive than its predecessor. The example above is relatively straightforward with behavior that is easy to follow if you’ve ever worked with Angular 1.x or a similar frontend MVC framework.

There are a number of other noteworthy ways in which Angular 2 improves on its predecessor. For example, Angular 2 makes extensive use of RxJS observables. Under the hood, change detection and data binding are also more performant and flexible. It relies on Zone.js to obviate the need for conventional dirty checking and $scope.$apply .

How does it compare to React and Angular 1.x?

Angular 2 is radically different from its predecessor. Although the decision to pursue a clean break is understandably controversial, the result is a much stronger framework. It’s not really clear, however, if that’s going to be enough to attract and sustain a large audience. Now that the React hype cycle has displaced Angular’s, it’s going to be hard for Angular 2 to overcome that loss of momentum.

The Angular 2 component model and tight integration with Typescript are very impressive, but don’t help to differentiate it much from React. It’s worth noting that Typescript supports React’s JSX template language, which means that you can also comfortably use Typescript to build React components.

As a matter of taste, some developers might prefer Angular’s clean, declarative approach to template markup over React’s JSX. Another key difference is that Angular aims to provide a more comprehensive ecosystem whereas React largely focuses on view rendering. Many React adherents view React’s simplicity and tight focus as a selling point, however.

It’s not clear that Angular 2 will win back many of the React converts, but developers who liked Angular and left it behind to get away from the performance overhead of dirty checking and the poor ergonomics of $scope.$apply can happily return knowing that those warts are now vanquished.

For existing Angular 1.x users, Angular 2 offers clear benefits in performance and ease of development. Migrating existing applications is going to be a manageable undertaking: the framework includes an adapter that enables incremental upgrades, letting developers mix Angular 1.x and Angular 2.x components in the same application. For existing Angular 1.x shops, switching to 2.x for new projects will likely be beneficial.

Next steps

I’ve published the full source code of my chat demo on GitHub. You can check it out and try it yourself. If you’d like to learn more about RethinkDB, visit our ten-minute guide.

Resources:

Found a typo? Help us improve this page.

What is RethinkDB?

RethinkDB is the open source database for the realtime web: learn how it works.

Your donation helps support RethinkDB’s future as an open-source project.

Основы Angular 2 — Привязка данных

Дата публикации: 2020-11-13

От автора: продолжаем изучать основы Angular 2. Двусторонняя привязка являлась часть функционала Angular JS, но из Angular 2.x и выше она была удалена. Однако сейчас, поскольку в Angular 2 доступны события классов, мы можем привязываться к свойствам в классе AngularJS.

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

Затем вы можете привязать свойство тега html к свойству класса.

Практический курс по созданию веб-приложения на Angular4

Скачайте БЕСПЛАТНЫЙ мини-курс и изучите базовые возможности JavaScript-фреймворка Angular 4 за ближайшие 3 дня

Тогда значение свойства будет присвоено htmlproperty html. Давайте рассмотрим на пример, как мы можем реализовать привязку данных. В нашем примере мы рассмотрим отображение изображений, в которых источник изображений будет получаться из свойств в нашем классе. Ниже приведены этапы реализации этого сценария.

Шаг 1 — Загрузите любые 2 изображения. В нашем примере мы загрузим несколько простых изображений, приведенных ниже.

Шаг 2 — Сохраните эти изображения в папке Images в каталоге приложения. Если папка Images у вас отсутствует, создайте ее.

Цукерберг рекомендует:  Java - Помогите с кодом Java
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих