Работу маршрутизатора мы можем разбить на 7 этапов:

1. Parse: разбирает  сроку запроса
2. Redirect: выполняет перенаправление (если нужно)
3. Identify: определяет стейт
4. Guard: запускает гарды конкретного стейта
5. Resolve: резолвит данные стейта
6. Activate: активирует компонент
7. Manage: слушает изменения, чтобы повторить процесс сначала

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

Parse

При разборе URL применяются следующие правила:

To parse the URL, Angular uses the following conventions:

• /: разбиваем на сегменты
• (): для вторичных роутов
• :: для задания именованых аутлетов 
• ;: задание параметров в матричной нотации
• ?,&: разделение параметров запроса
• #: задает фрагмент
• //: для разделения вторичных роутов

Исходя из этих правил, следующая строка:

/section-one;test=one/(nav:navigation;test=two//main:about;test=three)?query=four#frag

будет разобрана следующим образом:

Redirect

До создания стейта у нас есть еще фаза редиректа. Возможны 2 варианта редиректа:

• локальные (не начинаются со слеша и заменяют фрагмент)
• абсолютные (начинаются со слеша и полностью заменяют URL)

Identification

В этой фазе Роутер проходит по всем заданным стейтам и проверяет их на полное совпадение. Если полное совпадение не было найдено, он идет дальше.

Тут очень важно понимать, что при написании общих условий (wild card) они всегда должны идти в декларации ниже специфических.

Guards

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

Обратите внимание на порядок запуска гардов:

• CanDeactivate, CanActivateChild (запускаются снизу вверх: от самого вложенного к самому корневому)
• CanActivate (сверху вниз)
• CanLoad (запускается в случае, когда стейт требует ленивой подгрузки модуля)

Resolve

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

Activate

И вот только тут роутер доходит до шага активации компонента определенного для этого роута и его подстановки в DOM вместо router-outlet.

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

Роутер обновляет строку запроса браузера только тогда, когда компонент успешно инициализирован.

Manage

После того как произошла активация компонента и выведение его на экран, роутер снова слушает:

• изменения URL пользователем
• клики по routerLink
• вызовы router.navigate()

и при одном из этих действий начинает шаги с начала.

Вам была представлена последовательность действий роутера. Если вас интересует больше настройка роутера с примерами, то вам сюда.

View the code on Gist.

и сразу не понятно, что это магическая функция forwardRef. На самом деле все просто: forwardRef – это функция-обертка. Зачем она нужна? Чтобы мы могли задавать значением свойства сущности, которые объявлены ниже (иначе будет ошибка):

View the code on Gist.

Также можно глянуть в исходники, и убедиться что это просто метод-обертка:

View the code on Gist.

I had I chance to visit AngularCamp these days and would like to share some thoughts/notes with you.

Todd Motto & James Henry – From imperative to reactive thinking (slides)

Todd showed 2 great examples of streams of real world.

Bulbs that subscribed to one switch:

and coffee machine that makes different sorts of coffee out of water:

Next part was about comparing Imperative and Reactive approaches base on “game of throwing the ball” implementation.

Well… IMHO

Imperative: too much code, really difficult to follow

Reactive: got lost even knowing how to work with Rxjs

Dmitriy Shekhovtsov – Unleash The Power Of Angular With Knowledge of Patterns

Dmitriy started naming the patterns that everybody knows: singleton, factory, pub/sub, adapter to warmup audience, after continued with: DI, module, IoC,  CQRS to make some JS developers exited about new words.

Then he presented Dependancy injection pattern and provided 2 examples: with a fridge where parents “inject” food for the child and with carbonara that you don’t need to take care about ingredients. Frankly speaking, both examples highlighted an encapsulation principle more than DI. After he should how Angular code would look like without DI. I think it would be better to highlight the power of flexibility that DI provides you, instead of showing that

Module pattern was next one. Dmitriy highlighted that even with EcmaScript2015+ with native modules we still have to compile it to an old school function wrapper. Some good reasons why to use this pattern:

• namespaces
• encapsulation
• structured code
• manage dependancy

and after he compared it to ngModules: import, export, providers.

Also Dmitriy provided interesting idea to split you SharedModule into 2: to put all you services separately. In this case you would not need forRoot/forChild approach.

Next one was a Change Detection pattern. Some explanation about Javascript types and memory allocation, and “why the code worked in AngularJs and doesn’t work in Angular“. The answer is strict equality.

Several more words about immutability, pure functions and single responsibility.

Simona Cotin & Artur Daschevici – From Angular to React and back again

Simona and Artur provided kind of comparison for Angular and React(yes, yet another comparison ;) )

Simona started with Angular history, and told us what things had pushed AngularJs to be Angular:

• ES6
• Web components
• React
• RxJS
• Typescript
• EmberCli

and also, of course, it was a time for performance changes. so now we have:

• lazy loading
• AoT
• tree shaking

Then Artur took the floor and told us some parts of React:

• component based
• predictable state management
• ES6
• Flow
• Virtual DOM

Then they compared CLI tools and component declaration and tools for each framework.

Issues Angular:

• migration
  • Angular Style Guide
  • TypeScript
  • UpgradeModule
  • Upgrade cheatsheet

issues React:

• unmanageble large app
• state management
• no unified way of doing things

Victor Savkin – State Management Patterns and Best Practices with NgRxb

too much code for 4th talk without break… it looked like Viktor wanted to put 4 hours talk in 40 minutes….

* I’ll rewatch video one more time and will return back to you with more information about this topic.

Also Victor several times during the talk recommended this book:

Martin Splitt – Virtual Reality with A-Frame

Quite inspiring talk: Martin not only showed how to make VR in Javascript with help of simple library but also make all audience laugh.

He started with some examples of VR

• Tilt Brush: Painting from a new perspective
• Google Earth VR — Bringing the whole wide world to virtual reality

Compared different modern VR devices.

Explained How VR works.

I a bit of VR live coding with a-frame library.

Filip Bech-Larsen – Building dynamic SPA website

Filip showed results of his research how to build Angular over existing CMS: to use all management tools for content creation and editing and same time present it like SPA.

Pascal Precht – Angular and Service Workers

Progressive web apps (lighthouse – to check whether you app is progressive enough)

Service workers

Angular Service Worker

• install @angular/serviceworker
• angular-cli  serverWorker: true
• sw-register
• ngsw-manifest
• dynamic routing

Carmen Popoviciu – A moment’s reflection

Deep psychological talk about developer beings from Carmen that was nicely combined with Martin Splitt jokes.

Angular предлагает 2 подхода работы с формами:

• основанный на шаблонах (template-driven)
• реактивный (reactive)

Шаблонный более традиционный для декларативного подхода фреймворка. Реактивный появился позже и считается более прогрессивным и гибким. Мы разберем оба подхода.

Подключение модуля форм

Для начала работы с формами необходимо подключить модуль форм(FormsModule):

import { FormsModule } from '@angular/forms';

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

import { ReactiveFormsModule } from '@angular/forms';

И конечно импортируем их в наш основной модуль:

View the code on Gist.

Шаблоно-ориентированный подход (template-driven)

В шаблонно ориентированном подходе мы по большей части оперируем 3мя сущностями: ngModel, ngModelGroup и ngForm.

ngModel

Чтобы привязать данные к элементу формы мы можем поставить директиву ngModel:

<input type="text" [ngModel]="name">

Есть 3 способа как получить введенные данные:

• двухстороннее связывание
• обработку события изменения
• ссылку на элемент (либо ngModel)

ngModel и двухстороннее связывание (two way binding)

Способ, который пришел из AngularJs и в Angular практически не используется, но тем не менее, его хорошо знать:

<input type="text" [(ngModel)]="name">

то есть вы используете специальный синтаксис двойных скобок: сначала прямоугольные, затем круглые ( чтобы было проще запомнить последовательность используется подсказка “коробка с бананами” )

Теперь при вводе данных в элемент формы у нас будет обновляться и свойство контроллера name.

ngModel и обработка события

Вы можете использовать как родное событие поля ввода, например: для type text это будет input:

<input type="checkbox" [ngModel]="name" (input)="name = $event.target.value">

так и использовать специальное событие ngModelChange:

<input type="text" [ngModel]="name" (ngModelChange)="name = $event">

ngModel и обращение по ссылке

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

<input type="text" [ngModel]="name" #name>

теперь мы можем обратиться в шаблоне к значению свойства элемента:

{{name.value}}

либо в контроллере компонента через специальный декоратор ViewChild:

View the code on Gist.

Также мы можем сделать ссылку не только на элемент, но и на сам контроллер ngModel:

<input type="text" [ngModel]="name" #nameModel="ngModel">

Теперь в nameModel нам доступно не только значение модели, но и все дополнительные свойства и методы контроллера модели:

nameModel.valid

Валидация данных в шаблонном подходе

Полностью(или почти полностью) поддерживаются HTML5 валидация. То есть, например, если проставить полю атрибут require, то Angular его подхватит.

Свои валидаторы в шаблонном подходе

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

View the code on Gist.

таким образом мы создали свой валидатор, который проверит не является ли значение равным ‘3’. Плюс попрошу обратить ваше внимание на селектор для директивы мы указали не только сам атрибут имени директивы, но также что на элементе будет присутствовать ngModel.

Свои асинхронные валидаторы в шаблонном подходе

Полностью идентичны синхронным, отличие только в том что ваш метод валидации возвращает Promise либо Observable, а прописывается не в NG_VALIDATORS, в а NG_ASYNC_VALIDATORS:

View the code on Gist.

Вывод ошибок

Чтобы вывести ошибки также можем обратиться к контроллеру ngModel по ссылке и получить его свойство errors:

{{nameModel.errors | json}}

.

…и теперь…

.

Реактивный (reactive) подход

Реактивном подходе мы настраиваем элементы формы не в шаблоне, а в контроллере, оперируя при этом следующими понятиями: FormControl, FormGroup, FormArray, FormBuilder.

На каждый элемент формы создается(вручную или автоматически) свой FormControl.

FormControl

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

name: FormControl = new FormControl('Alice');

и привязываем его к конкретному элементу в шаблоне:

<input type="text" [formControl]="name">

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

this.name.valueChanges.subscribe(console.log)

Либо на изменения статуса(валидности):

this.name.statusChanges.subscribe(console.log)

this.name.value
this.name.valid

FormGroup

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

View the code on Gist.

и подключаем в шаблоне:

View the code on Gist.

Обратите внимание, что для контролов обернутых в formGroup мы уже ставим formControlName свойство (а не [formControl]), которое будет указывать на то, где брать контрол в группе.

FormArray

FormArray прекрасно подойдет тогда, когда в форме у вас используется список, в который вы можете добавлять элементы. Давайте сделаем форму “учасников”, которая содержит список участников:

View the code on Gist.

и в шаблоне это будет выглядеть так:

View the code on Gist.

как видите мы выводим список контролов используя итератор(index) как имя контрола(formControlName) в списке.

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

View the code on Gist.

и для этого в контроллере компонента определим 2 дополнительных метода removeUser и addUser:

View the code on Gist.

В итоге получим:

FormBuilder

Упростить процесс создания новых форм нам помогает сервис FormBuilder. Который мы можем инжектировать в контроллер:

View the code on Gist.

После чего создать туже форму (“учасники”), только теперь с помощью сервиса:

View the code on Gist.

вы можете сказать, что кода не стало меньше. Да, это так. FormBuilder имеет смысл использовать только для сложных форм с большим динамическим количеством контролов.

Валидация данных в реактивном подходе

Чтобы добавить валидатор на контрол мы всего лишь добавляем второй параметр, который может быть как одним валидатором, так и массивом(применяем разные проверки):

name: FormControl = new FormControl('Alice', [Validators.required]);

предварительно импортировав коллекцию валидаторов:

import { Validators } from “@angular/forms”;

Мы можем задавать один и больше валидатор. На данный момент в коллекции есть следующие валидаторы:

• min
• max
• required
• requiredTrue
• email
• minLength
• maxLength
• pattern

Создание своих валидаторов

Валидатор представляет из себя простую функцию, которая возвращает либо объект ошибки либо null:

View the code on Gist.

добавляется вторым параметром в контрол( вместе со стандартными валидаторами):

name: FormControl = new FormControl('Alice', [Validators.required, myNameValidator]);

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

Валидаторы с параметрами

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

View the code on Gist.

Асинхронные валидаторы

Асинхронные валидаторы отличаются от синхронных только тем, что возвращают не статические данные, а Observable либо Promise:

View the code on Gist.

и также определяются 3-м параметром в конструкторе контрола:

name: FormControl = new FormControl('Alice', [myNameValidator], [myAsyncNameValidator]);

Вывод ошибок

Ошибки контрола хранятся в свойстве errors:

this.name.errors

Чтобы сделать какие-то действия в случае появления ошибок, можем написать так: добавив фильтры на изменение состояния и собственно валидность данных:

View the code on Gist.

Свойство есть не только у обычного контрола, но так же и у FormGroup, поэтому вы можете получить объект со всеми ошибками формы:

this.participantsForm.errors

Создание кастомных контроллов

Решил вынести эту главу в отдельный пост.

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

Предположим что у нас уже есть какой-то компонент, который мы хотим вывести на странице не Angular приложения:

View the code on Gist.

Для запуска Angular нам нужно также создать модуль, объявить наш компонент в нем и указать на то, что он будет инициирован динамически:

View the code on Gist.

Создав модуль, мы можем его бустрапить:

View the code on Gist.

Использование фабрики компонентов

Чтобы инициировать динамически компонент, нам нужен componentFactoryResolver, который мы можем получить из сущности нашего модуля:

View the code on Gist.

теперь можем получить фабрику для нашего конкретного компонента:

View the code on Gist.

и с помощью полученной фабрики создать компонент:

View the code on Gist.

обратите внимание, что мы произвели создание компонента прям на самом элементе (querySelector(‘hello‘)), но это не обязательно, мы бы также могли инициализировать контейнер, который содержит наш hello-элемент (например body).

Мы вывели компонент на страницу.

Но еще не все.

Подключаем механизм обнаружения изменений (Change Detection)

Чтобы представление нашего компонента реагировало на изменение состояния приложения, нам необходимо добавить hostView компонента в приложение (ApplicationRef). Для этого используем метод attachView:

 ngModuleRef.injector.get(ApplicationRef).attachView(componentRef.hostView);

Получим:

View the code on Gist.

Также мы можем сделать отложенную инициализацию по таймеру (например: через 5 секунд):

View the code on Gist.

Вот тут полный пример.

• оператор не нулевого присвоения ( Non-null assertion operator ) теперь можно использовать в шаблонах:

  <h2>{{ user!.name }}</h2>

• очень много изменений по анимации (смотрите в отдельном посте)
• добавили поддержку mix & max стандартных валидаторов (но уже в 4.3.0-beta.0 удалили эту возможность признав как breaking change)
• в тестах появились 3 вспомогательных метода:
  • TestBed.overrideProvider() – приближает возможность тестировать в AOT,
  • flush() – для сбрасывания всех счетчиков и выполнения колбэков всех асинхронных операций,
  • fixture.whenRenderingDone() – возвращает промис, который ждет выполнения всех анимаций

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

Нужно отписываться

Формы

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

View the code on Gist.

Роутер

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

View the code on Gist.

Рендерер

View the code on Gist.

Бесконечные обозреваемые последовательности

Примерами бесконечных могут служить последовательности созданные с помощью interva() или слушающие события (fromEvent()):

View the code on Gist.

ngRx

От подписок на состояние Store ngRx тоже необходимо отписываться:

View the code on Gist.

Отписываться НЕ нужно

Async pipe

C async pipe нам повезло и он выполнят работу под отписке за нас:

View the code on Gist.

@HostListener

так же нам не нужно отписываться, когда мы навешиваем слушатель события с помощью HostListener:

View the code on Gist.

Конечные обозреваемые последовательности

Бывают последовательности, которые сами завершаются, такие как HTTP и timer:

View the code on Gist.

Bonus

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

View the code on Gist.

Кроме takeUntil вы еще можете использовать take, takeWhile и first которые также позволят “убить” последовательность, соотвественно не прийдется от нее отписываться.

Большая часть материала взята из статьи When to Unsubscribe in Angular.

1 Как получить конструктор-метод директивы из консоли?

2 Как создать новый скоуп снаружи ангуляра (не находясь внутри сущности)?

3 Чем отличается service, factory, provider?

4 Как “выключить” вотчер?

5 Как использовать экземпляр сервиса внутри app.config? (Ангуляр допускает использование только провайдеров, при прямом внедрении)

6 В базе данных хранится ангуляровское выражение, как вывести его результат на фронтенд?

7 Что будет если определить 2 сущности с одним и тем же именем: для модуля, сервиса, директивы?

8 Если у вас есть директива1 и вложенная в нее директива2, то в каком порядке будут запущены controller и link методы этих директив?

9 Какой тип scope создает ui-view директива? (ui-router модуль)

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

Существует множество ресурсов по изучению Redux: официальная документация, примеры, учебники, статьи, видео уроки… Имея такое большое количество информации многие начинающие Redux разработчики порой просто теряются в ней.

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

Не беспокойтесь, это совсем не сложно. Ядро Redux, как вы убедитесь, достаточно просто.

Для начала нам необходимо общее понимание что делает Redux.

Что конкретно делает Redux?

Основная идея Redux – всегда иметь единственное состояние приложения. Это состояние представляет из себя Javascript объект – Redux Store, который доступен только для чтения. Если вы хотите изменить состояние, то вам нужно породить Action, что тоже является Javascript объектом.

Элементы вашего приложения могут подписываться на изменение состояния Store. Если мы посмотрим на примере с React, то компоненты React получают уведомление о изменении состояния и могут изменить отображение базируясь на новых данных.

Чтобы обновить Store, когда приходит Action, используется Reducer – обычная Javascript функция.

Давайте начнем писать код!

Обобщая, мы должны сделать 3 вещи:

1. Получать состояние приложение из Store
2. Разобрать событие Action, которое будет передано на Reducer, который изменит состояние Store.
3. Следить за изменениями Store

Так же мы должны определить начальные значения для Store и Reducer, давайте с этого начнем:

View the code on Gist.

1. Получение состояния (state)

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

View the code on Gist.

2. Отправка события (dispatch an action)

Следующий шаг – отправка события:

View the code on Gist.

Функция dispatch используя текущее состояние отправляет событие на редьюсер, который мы определили при инициализации. А он в свою очередь перезаписывает объект currentState новым значением.

3. Подписка на изменения

Теперь мы можем получать и обновлять состояние! Оставшийся шаг – сделать возможность подписаться на изменения:

View the code on Gist.

Теперь мы можем вызывать subscribe с коллбэк-параметром, который будет вызван в случае получения события на изменнеие состояния.

Все готово.

Это все что нам нужно было сделать для создания mini-Redux.

На официальной github странице есть пример как использовать Redux. Мы можем скопировать пример, чтобы протестировать нашу собственную реализацию Redux:

View the code on Gist.

Поиграться с кодом можно тут.

Выводы

Мы разработали рабочую версию аналога Redux, которая уместилась в 18 строчках кода. Впечатляет, правда?

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

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