Хочу представить перевод довольно интересной статьи Сэма Редмонда, Why We Should Throw Out React and Pick Up Angular. На мой взгляд, статья описывает основные возможности Angular. Она может показаться довольно вызывающей, но постарайтесь отнестись к ней немного с юмором :)

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

1. Он популярен в основном от того, что вокруг него много шумихи.

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

3. Использует не оправдано много памяти и не поддаётся оптимизации(not tree-shakable).

4. Сложность React приложения растёт экспоненциально с ростом размера приложения и это затрудняет его обслуживание.

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

6. Обновление вашего приложения до последней версии React часто сопряжено с полным переписыванием этого самого приложения.

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

All aboard the hype train

Angular также получает изрядное количество хайпа, так что я не могу сказать, что Angular решает эту проблему. Однако, я не думаю, что Angular получает такое же количество хайпа, как React. Мне кажется, что в основном это связано с ребрендингом, который сделал Google.. Сначала был AngularJs, который был как дымящаяся куча мусора. Но надо отдать должное Google, они решили полностью отремонтировать AngularJs и превратить его в Angular (или Angular 2), что является гигантским улучшением. Впрочем, это улучшение стоило ему популярности, как мне кажется.

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

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

Вы получаете то, что вам нужно

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

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

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

Одна из самых больших проблем с React - это отсутствие стандартов. Если вы изучили одно React приложение, то вы изучили одно React приложение, потому что все они совершенно разные. С другой стороны, если вы изучили одно Angular приложение, то вы изучили все Angular приложения и Angular CLI является основным драйвером, стоящим за этим.

В отличие от React в Angular есть правильные и неправильные способы. Использование Angular CLI обычно всегда гарантирует, что всё будете делать правильно. Давайте возьмём самое начало. Мы хотим создать новое приложение. Как мы это сделаем?

ng new my-app

Да, вот, пожалуй и всё. Запустите эту команду и CLI настроит кучу вещей за вас. Он даже даст вам некоторый выбор, такой как использование линтинга и роутинга, перед тем, как будет создано приложение. Итак, вот что сделает CLI:

1. Он создаст новую директорию my-app и проинициализирует в ней Angular приложение. А также установит зависимости.

2. Настраивает инфраструктуру и интегрирует в неё приложение, снабдив вас всем, что нужно для запуска.

3. Вместе с инфраструктурой вы также получаете встроенную базовую реализацию end-to-end тестов на Protractor, в которую вы можете добавлять тесты, по мере развития вашего приложения.

4. Angular даёт вам простой в использовании конфигурационный файл (angular.json). В нём вы можете легко настроить, как Angular собирает приложение и даже то, как эта сборка делается средой окружения.

5. Говоря о среде окружения, Angular имеет в своём составе простую и хорошо типизированную систему управления этой самой средой.

Ещё много есть того, чего я возможн коснусь, но и это уже очень круто, да ещё и прямо из коробки. В React вы такого не получите. Что ещё даёт вам CLI?

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

ng generate component my-component OR ng g c my-component

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

1. Создаёт директорию с именем my-component и помещает в него пустой компонент.

2. Автоматически генерирует unit tests для данного компонента.

3. Автоматически встраивает ваш компонент в инфраструктуру приложения.

Путь Angular

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

https://stackblitz.com/edit/angular-examples-modules

ng g m buttonng g c button

В этом примере у нас есть папка button. В этой папке есть модуль button, компонент button, тестовый файл, файл стилей и HTML файл.

Это было автоматически сгенерировано Angular CLI. Если вы заметили, команды имеют определённый порядок и на это есть причина. Во-первых нам нужен модуль, чтобы включить в него наш компонент button. Затем мы создаём компонент button и CLI автоматически импортирует его в модуль. Затем мы экспортируем наш компонент для того, чтобы мы могли использовать его в других модулях нашего приложения.

Чтобы всё было просто, давайте импортируем это в app.module.ts. Всё, что мы сделаем, это импортируем наш компонент ButtonModule в app.module.ts и потом включим его в раздел imports декоратора @NgModule приложения AppModule.

Вот и всё. Теперь мы можем использовать тэг <app-button></app-button> в app.component.html файле.

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

Доставьте меня из пункта А в пункт Б

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

Как хороший CLI, Angular имеет опции. Одна из них задействует роутинг во время создания инфраструктуры приложения.

ng new my-app --routing

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

В созданном конфиге роутинга вы сможете легко настроить ленивую загрузку модуля:

const routes: Routes = [   {   path: 'main',   loadChildren: () =>    import('src/app/routes/main/main.module').then((mod) => mod.MainModule)   },];

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

Переиспользование делает вашу жизнь проще

Итак, мы рассмотрели, как Angular использует Modules для организации страниц и компонент и хочу остановиться на этом немного подробнее. Вероятно, что вы уже знаете, что Angular использует TypeScript вместо обычного javascript. Это явное преимущество Angular использует в полной мере.

Полагаю, что вы уже говорите - React тоже использует TypeScript, и будете правы. Но React использует Typescript не в полной мере. Типизация - это только часть того, что делает TypeScript таким продвинутым. Другая часть состоит в том, что вы можете в полной мере использовать классы и декораторы. React дал ясно понять, что движется в сторону функциональных компонент, а не в сторону компонент основанных на классах, что отнимает половину всей мощи TypeScript. Теперь стало намного сложнее переиспользовать функциональность в моём приложении и оно стало более сложным в обслуживании.

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

@my-decorator()export class MyClass {}

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

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

Understanding Angular Ivy: Incremental DOM and Virtual DOM

В предыдущей статье я немного рассказывал о том, что виртуальный DOM это своего рода пожиратель памяти и что невозможно оптимизировать расход этой памяти (tree shaking), поскольку виртуальное дерево создаётся всякий раз заново при перерисовке. Всё изменилось с приходом Angular Ivy. Вы сможете прочитать как работает Ivy в статье Виктора. Я лишь приведу некоторые моменты из неё.

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

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

Помните, как я ранее сказал: Я уже знаю, что вы думаете и мы к этому вернёмся? Давайте разберём это. В том месте статьи я уверен, что вы подумали про себя: это всё прелестно, но что если мне не понадобиться ВСЁ, что Angular предоставляет? Хорошо, ну вы сами вдумайтесь, если вы не используете какую-то часть Angular, она просто не попадёт в сборку! Их технология оптимизации сборки постоянно улучшается и вы получите более стройные билды, в особенности если вы не используете абсолютно всё, что есть в Angular.

Апгрейд - проще простого

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

Я долго работал с Angular и видел все апдейты с первого релиза (я даже работал с AngularJs, но предпочитаю не говорить об этом). Безусловно Angular прошёл долгий путь, как и CLI. Где в 2018 году в Angular CLI появилась ещё одна команда - ng update. Вы можете использовать её так:

ng update @angular/core

Дальше происходит магия. Все зависимости ядра Angular обновятся до последней версии. Если ваш код нуждается в обновлении, CLI сделает это за вас и, если нельзя, то скажет, где вам нужно самим вручную обновить свой код. Обновление до последней версии Angular займёт от нескольких секунд до нескольких минут, в то время, как с React это может занять от нескольких часов до нескольких дней (или даже недель).

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

Давайте свяжем всё вместе

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

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

Хорошая совместимость - уменьшение сложности обслуживания. Когда ваш проект растёт, стоимость обслуживания не будет возрастать экспоненциально. Наверное это самая большая проблема в React приложениях, которую превосходно решает Angular. Следуя тому же ходу мысли, мы также получаем всё, что нам нужно прямо из ядра Angular. Обработка форм? Пожалуйста. Роутинг? Пожалуйста. Ленивая загрузка? Пожалуйста. Я мог бы продолжить, но остановлюсь на этом. Даже если вы что-то не используете, то это не войдет в ваш билд, потому что всё, что в ядре Angualr является оптимизируемым деревом (tree shakable), включая рендеринг.

Чтобы завершить статью, скажу последнее. Используйте Angular. Смотрите видео на YouTube. Читайте документацию или учитесь, как у вас получается лучше всего. А затем смело бросайте React в мусор, потому что он вам больше не понадобится.

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

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

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

Основная Идея

Есть неизменяемый объект, который представляет все значения полей некоторого компонента:

Каждый раз, когда какое-либо поле (или несколько значений полей) компонента изменяется, то создается новый неизменяемый объект, содержащий комбинацию старых и новых значений:

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

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

Простая Форма Приветствия

Давайте создадим простую форму приветствия (исходный код на stackblitz):

simple-greeting-form.component.ts

@Component({  selector: 'app-simple-greeting-form',  templateUrl: './simple-greeting-form.component.html'})export class SimpleGreetingFormComponent {  userName: string;  greeting:  string;}

simple-greeting-form.component.html

<div class="form-root">    <h1>Greeting Form</h1>  <label for="ni">Name</label><br />  <input [(ngModel)]="userName" id="ni" />  <h1>{{greeting}}</h1></div>

Очевидно, что поле greeting зависит от поля userName, и существует несколько способов выразить эту зависимость:

1. Преобразовать greeting в свойство с геттером, но в этом случае его значение будет вычисляться в каждом цикле обнаружения изменений (change detection);

2. Преобразовать userName в свойство с сеттером, который обновит значение поле greeting;

3. Создать обработчик событийя ngModelChange, но это избыточно усложнит код;

Эти способы будут работать, но если какое-то другое поле зависит от приветствия (greeting, greeting counter) или greeting зависит от нескольких полей (например, greeting = f (userName, template)), то ни один из этих методов не поможет, поэтому предлагается другой подход:

@Component(...)@StateTracking()export class SimpleGreetingFormComponent {  userName: string;  greeting:  string;  @With("userName")  public static greet(state: ComponentState<SimpleGreetingFormComponent>)    : ComponentStateDiff<SimpleGreetingFormComponent>  {    const userName = state.userName === ""       ? "'Anonymous'"       : state.userName;    return {      greeting: `Hello, ${userName}!`    }  }}

Для начала компонент должен быть отмечен декоратором @StateTracking или же в конструкторе должна быть вызвана функция initializeStateTracking (декораторы компонентов иногда работают некорректно в некоторых старых версиях Angular):

@Component(...)export class SimpleGreetingFormComponent {  userName: string;  greeting:  string;    constructor(){    initializeStateTracking(this);  }}

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

Далее определяем функцию перехода в новое состояние:

  ...  @With("userName")  public static greet(state: ComponentState<SimpleGreetingFormComponent>)    : ComponentStateDiff<SimpleGreetingFormComponent>  {      ...  }  ...

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

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

Если же вы определите третий параметр, то он получит объект разницы между текущим и предыдущим состояниями:

@With("userName")public static greet(  state: ComponentState<SimpleGreetingFormComponent>,  previous: ComponentState<SimpleGreetingFormComponent>,  diff: ComponentStateDiff<SimpleGreetingFormComponent>): ComponentStateDiff<SimpleGreetingFormComponent>{  ...}

ComponentState и ComponentStateDiff это прокси типы (Typescript mapped types), которые отфильтровывают методы и источники событий (event emitters). Также ComponentState отмечает все поля как только для чтения (ведь состояние неизменяемо (immutable)), а ComponentStateDiff отмечает все поля как необязательные, поскольку функция перехода может возвращать любое подмножество исходного состояния.

Для простоты определим алиасы этих типов:

type State = ComponentState<SimpleGreetingFormComponent>;type NewState = ComponentStateDiff<SimpleGreetingFormComponent>;...  @With("userName")  public static greet(state: State): NewState  {    ...  }

Декоратор @With получает список имен полей, изменение значений которых вызовет соответствующий декорированный статический (!) метод класса компонента. Typescript проверит, что класс на самом деле содержит объявленные поля и что метод является статическим (функции переходов должны быть чистыми (pure)).

Логирование изменений

Теперь форма отображает соответствующее приветствие при любом изменении имени. Посмотрим, как меняется состояние компонента:

@Component(...)@StateTracking<SimpleGreetingFormComponent>({  onStateApplied: (c,s,p)=> c.onStateApplied(s,p)})export class SimpleGreetingFormComponent {  userName: string;  greeting:  string;  private onStateApplied(current: State, previous: State){    console.log("Transition:")    console.log(`${JSON.stringify(previous)} =>`)    console.log(`${JSON.stringify(current)}`)  }  @With("userName")  public static greet(state: State): NewState  {      ...  }  }

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

Transition:{} =>{"userName":"B","greeting":"Hello, B!"}Transition:{"userName":"B","greeting":"Hello, B!"} =>{"userName":"Bo","greeting":"Hello, Bo!"}Transition:{"userName":"Bo","greeting":"Hello, Bo!"} =>{"userName":"Bob","greeting":"Hello, Bob!"}

Как мы видим, компонент переходит в новое состояние каждый раз, когда пользователь вводит следующий символ имени, и поле приветствия при этом немедленно обновляется. Если необходимо предотвратить обновление приветствия при каждом изменении имени, то это можно легко сделать, добавив расширение Debounce к декоратору @With:

@With("userName").Debounce(3000/*ms*/)public static greet(state: State): NewState{    ...}...

Теперь библиотека ждет 3 секунды после последнего изменения в имени и только затем выполняет переход:

Transition:{} =>{"userName":"B"}Transition:{"userName":"B"} =>{"userName":"Bo"}Transition:{"userName":"Bo"} =>{"userName":"Bob"}Transition:{"userName":"Bob"} =>{"userName":"Bob","greeting":"Hello, Bob!"}

Добавим индикацию того, что форма находится в режиме ожидания:

...export class SimpleGreetingFormComponent {  userName: string;  greeting:  string;  isThinking:  boolean = false;  ...  @With("userName")  public static onNameChanged(state: State): NewState{    return{      isThinking: true    }  }  @With("userName").Debounce(3000/*ms*/)  public static greet(state: State): NewState  {    const userName = state.userName === ""       ? "'Anonymous'"       : state.userName;    return {      greeting: `Hello, ${userName}!`,      isThinking: false    }  }}

...<h1 *ngIf="!isThinking">{{greeting}}</h1><h1 *ngIf="isThinking">Thinking...</h1>...

Кажется, что это работает, но есть проблема - если пользователь начал печатать, а затем решил вернуть исходное имя в течение заданных 3 секунд, то с точки зрения библиотеки поле greeting не изменилось, и функция перехода не будет вызвана, а форма будет показывать Thinking до тех пор, пока вы не набираете другое имя. Это можно решить, добавив декоратор @Emitter() для поля userName:

@Emitter()userName: string;

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

Однако есть и другое решение - когда форма перестает "думать", она может установить для userName значение null, и тогда пользователю придется начать вводить новое имя:

...@With("userName")public static onNameChanged(state: State): NewState{  if(state.userName == null){    return null;  }  return{    isThinking: true  }}@With("userName").Debounce(3000/*ms*/)public static greet(state: State): NewState{  if(state.userName == null){    return null;  }    const userName = state.userName === ""     ? "'Anonymous'"     : state.userName;  return {    greeting: `Hello, ${userName}!`,    isThinking: false,    userName: null  }}...

А теперь давайте подумаем о ситуации, когда пользователь нетерпелив и хочет сразу получить результат. Что ж, позволим ему нажать [Enter] ((keydown.enter) = "onEnter ()"), чтобы немедленно получить приветствие:

...userName: string | null;immediateUserName: string | null;onEnter(){  this.immediateUserName = this.userName;}...@With("userName")public static onNameChanged(state: State): NewState{  ...}@With("userName").Debounce(3000/*ms*/)public static greet(state: State): NewState {  ...}@With("immediateUserName")public static onImmediateUserName(state: State): NewState{  if(state.immediateUserName == null){    return null;  }  const userName = state.immediateUserName === ""     ? "'Anonymous'"     : state.immediateUserName;  return {    greeting: `Hello, ${userName}!!!`,    isThinking: false,    userName: null,    immediateUserName: null  }}...

Ещё было бы неплохо узнать, сколько времени ждать, если пользователь не нажимает [Enter] - какой-нибудь счетчик обратного отсчёта был бы очень полезен:

<h1 *ngIf="isThinking">Thinking ({{countdown}} sec)...</h1>

...countdown: number = 0;...@With("userName")public static onNameChanged(state: State): NewState{  if(state.userName == null){    return null;  }  return{    isThinking: true,    countdown: 3  }}...@With("countdown").Debounce(1000/*ms*/)public static countdownTick(state: State): NewState{  if(state.countdown <= 0) {    return null  }  return {countdown: state.countdown-1};}

и вот как это выглядит:

Обратный отсчет также следует сбрасывать каждый раз, когда готово новое приветствие. Это предотвращает ситуацию, когда пользователь сразу нажимает [Enter], а обратный отсчет в этот момент остается 3 - после этого он перестает работать, так как его значение больше никогда не изменится. Для простоты сбросим все поля, зависящие от флага isThinking:

...@With("isThinking")static reset(state: State): NewState{  if(!state.isThinking){    return{      userName: null,      immediateUserName: null,      countdown: 0    };  }  return null;}...

Обнаружение Изменений (Change Detection)

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

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

...constructor(readonly changeDetector: ChangeDetectorRef){}...private onStateApplied(current: State, previous: State){  this.changeDetector.detectChanges();  ...

Теперь он работает должным образом даже с OnPush стратегией обнаружения (Change Detection Strategy).

Исходящие Параметры (Output Properties)

Библиотека обнаруживает все источники событий (Event emitters) компонентов и вызывает их, когда поменялись значения привязанных к этим источникам полей. По умолчанию привязка выполняется с использованием суффикса Change в названиях источников событий:

greeting:  string;@Output()greetingChange = new EventEmitter<string>();

Распределенное Состояние

Обычно, когда компонент уничтожается (например, скрывается с помощью *ngIf), все ещё не завершенные асинхронные операции, инициированные этим компонентом, заканчиваются без каких либо значимых изменений. Однако библиотека позволяет выделить состояние компонента со всеми его переходами в отдельный объект, который может существовать независимо от компонента. Более того, такой объект может использоваться несколькими компонентами одновременно!

Давайте превратим компонент формы приветствия в сервис:

greeting-service.ts

@StateTracking({includeAllPredefinedFields:true})export class GreetingService implements IGreetingServiceForm {  userName: string | null = null;  immediateUserName: string | null = null;  greeting:  string = null;  isThinking:  boolean = false;  countdown: number = 0;  @With("userName")  static onNameChanged(state: State): NewState{    ...  }  @With("userName").Debounce(3000/*ms*/)  static greet(state: State): NewState  {    ...  }  @With("immediateUserName")  static onImmediateUserName(state: State): NewState{    ...  }  @With("countdown").Debounce(1000/*ms*/)  static countdownTick(state: State): NewState{    ...  }  @With("isThinking")  static reset(state: State): NewState{    ...  }}

и добавим его в провайдеры главного модуля.

includeAllPredefinedFields означает, что все поля с некоторым начальным значением (даже если оно null) будут автоматически включены в объекты состояния.

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

1. Внедрить экземпляр службы в компонент через dependency injection;

2. Передать экземпляр сервиса в инициализатор трекера состояния;

3. Отметить поля компонента, которые будут привязаны к соответствующим полям сервиса;

4. Подписаться на изменения состояния сервиса - это необходимо, когда требуется явное обнаружение изменений или стратегия обнаружения изменений - OnPush.

После выполнения этих шагов компонент будет выглядеть так:

@Component({...  changeDetection: ChangeDetectionStrategy.OnPush})export class ComplexGreetingFormComponent   implements OnDestroy, IGreetingServiceForm {  private _subscription: ISharedStateChangeSubscription;  @BindToShared()  userName: string | null;  @BindToShared()  immediateUserName: string | null;  @BindToShared()  greeting:  string;  @BindToShared()  isThinking:  boolean = false;  @BindToShared()  countdown: number = 0;  constructor(greetingService: GreetingService, cd: ChangeDetectorRef) {    const handler = initializeStateTracking<ComplexGreetingFormComponent>(this,{      sharedStateTracker: greetingService,      onStateApplied: ()=>cd.detectChanges()    });    this._subscription = handler.subscribeSharedStateChange();  }  ngOnDestroy(){    this._subscription.unsubscribe();  }  public onEnter(){    this.immediateUserName = this.userName;  }}

Экземпляр службы передается в функцию initializeStateTracking (также возможно использование декоратора @StateTracking(), но это потребует больше усилий), которая возвращает объект с помощью методов которого можно управлять работой библиотеки в указанном компоненте.

Подписка (_subscription: ISharedStateChangeSubscription) требуется для вызова функции обратного вызова onStateApplied при изменении состояния сервиса или для вызова локальной функции перехода, которая зависит от поля (полей) сервиса. Если компонент использует стратегию обнаружения изменений Default и отсутствуют локальные функции перехода, то подписка не требуется.

Не забудьте отказаться от подписки при уничтожении компонента, дабы избежать утечек памяти. В качестве альтернативы вы можете вызвать функции handler.release() или releaseStateTracking(this), чтобы отказаться от подписок на компоненты, но эти методы также отменяют все незавершенные асинхронные операции, что не всегда желательно.

Составное Распределенное Состояние

Библиотека позволяет использовать общие состояния не только в компонентах, но и в других сервисах.

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

export type LogItem = {  id: number | null  greeting: string,  status: LogItemState,}@Injectable()export class GreetingLogService implements IGreetingServiceLog, IGreetingServiceOutput {  @BindToShared()  greeting:  string;  log: LogItem[] = [];  logVersion: number = 0;  identity: number = 0;  pendingCount: number = 0;  savingCount: number = 0;  ...  constructor(greetingService: GreetingService){    const handler = initializeStateTracking(this,{      sharedStateTracker: greetingService,       includeAllPredefinedFields: true});          handler.subscribeSharedStateChange();      }  ...}

При каждом изменении значения поля greeting, это значение будет добавлено в массив журнала log. logVersion будет увеличиваться каждый раз при изменении массива, чтобы обеспечить обнаружение изменений, не делая при этом массив журнала неизменяемым:

...@With("greeting")static onNewGreeting(state: State): NewState{    state.log.push({id: null, greeting: state.greeting, status: "pending"});    return {logVersion: state.logVersion+1};}...

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

@With("logVersion")static checkStatus(state: State): NewState{  let pendingCount = state.pendingCount;  for(const item of state.log){    if(item.status === "pending"){      pendingCount++;    }    else if(item.status === "saving"){      savingCount++;    }  }  return {pendingCount, savingCount};}@With("pendingCount").Debounce(2000/*ms*/)static initSave(state: State): NewState{  if(state.pendingCount< 1){    return null;  }  for(const item of state.log){    if(item.status === "pending"){      item.status = "saving";    }  }  return {logVersion: state.logVersion+1};}

И наконец, собственно, сама отправка на сервер:

...  @WithAsync("savingCount").OnConcurrentLaunchPutAfter()  static async save(getState: ()=>State): Promise<NewState>{      const initialState = getState();      if(initialState.savingCount < 1){        return null;      }      const savingBatch = initialState.log.filter(i=>i.status === "saving");      await delayMs(2000);//Simulates sending data to server       const stateAfterSave = getState();      let identity = stateAfterSave.identity;      savingBatch.forEach(l=>{        l.status = "saved",        l.id = ++identity      });      return {        logVersion: stateAfterSave.logVersion+1,        identity: identity      };        }...

Эта функция перехода отличается от предыдущих тем, что она асинхронная:

1. Она отмечена декоратором WithAsync вместо With;

2. Декоратор имеет спецификацию поведения параллельного запуска (в данном случае OnConcurrentLaunchPutAfter);

3. Вместо объекта текущего состояния он получает функцию, которая возвращает текущее состояние в момент вызова.

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

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

1. Код статьи на stackblitz: https://stackblitz.com/edit/set-state-greet;

2. Ссылка на пердыдущую статью: Angular Components with Extracted Immutable State;

3. Ссылка не исходный код ng-set-state: https://github.com/0x1000000/ngSetState