Реактивные приложения на Angular/NGRX. Часть 1. Введение.
Когда я только начал изучать angular 2+, я был так счастлив возможностям, которые он дает разработчикам. Особенно после опыта с первой версией — все становится намного прозрачнее и проще.
У нас имеются компоненты, которые способны хранить состояние, то есть в свойствах класса мы храним данные, которыми оперируем (например массив книг в компоненте book-list или конкретный экземпляр книги в компоненте book-detail). И это до невозможности удобно. Мы можем передавать наши данные дочерним компонентам посредством component-binding и сообщать родительским, если произошли какие-то изменения с помощью EventEmitter. Куда ещё проще? Есть родительские и дочерние компоненты, их древовидная структура и change detection, который следит за изменением state-а каждого компонента.
Так же у нас есть service-ы, в которых можно хранить определенное состояние. По средством depency injection мы передаем их в компоненты, создавая связь между ними, будь наш компонент подписчиком определенных данных или наоборот инициатором изменений.
Перед нами открыто много возможностей. Слишком много.
И порой это может перерасти в проблему. Только представьте, у вас имеется, например, 20 компонентов и в каждом из них собственное состояние, которое хранит определенный набор данных, в свою очередь, некоторые компоненты имеют возможность менять эти данные, а другие компоненты напрямую от них зависят от других данных. То есть может случится ситуация, когда все друг от друга зависят и будет очень хорошо, если вы будете следить за этим модулем\проектом вечно, зная наизусть все связи. Но даже в таком случае это сложно.
Но так уж сложилось, что чаще всего, нужно создавать новые функции, менять старые или вообще работать над новыми проектами или поддерживать старые. Мы забываем, буквально, через месяц, то над чем работали и если посмотреть на прошлый спагетти код, то на восстановление контекста в голове может уйти немало времени.
Изменяемое состояние само по себе не является источником зла, но общедоступное изменяемое состояние - может стать большой проблемой.
Итак, поняв проблему, нам следует выделить её основные моменты и начать поиск решения.
- Состояние наших компонентов не должно быть хаотичным, мы должны видеть зависимости явно.
- Источник изменения состояния должен быть известен. Если состояние было изменено, нам следует знать, кто являлся источником.
- Изменения состояния не должны происходить во всех местах нашего приложения (компонентах, service-ах). Желательно отделить эту часть приложения для быстрого понимания архитектуры приложения.
Имея список проблем, посмотрим, что нам предлагает ngrx и сделаем вывод — решает ли он вышеописанные проблемы.
NGRX
Данный пакет модулей имплементирует redux-паттерн и дает возможность воспользоваться некоторыми приемами, помогающими сделать наше приложение более гибким и масштабируемым.
При использовании ngrx наше приложение будет иметь:
- Единственно точный источник данных и его удобное использование в компонентах
- Изменение состояния только посредством чистых функций — reducers
- Инициализация изменений может осуществляться посредством отправки действий (actions) — описывающих тип изменений и содержащих полезную нагрузку (payload).
- 2 типа компонентов (контейнер\представление)
- Изоляцию side-effect-ов.
- Мощный time-travelling дебаггер
Остальные пункты опциональны (управление сущностями (entity) из коробки, синхронизация router и store, кодогенерация и т.д.)
Хорошо, выглядит не плохо, но что это все значит? А значит это следующее:
- Однонаправленный и ясный поток данных (unidirectional data flow)
- Ясное понимание изменений состояния приложения
- Разделение изменения состояния от слоя представления
Так как redux очень и очень распространенный паттерн за последние несколько лет во фронтенде, это определенным образом унифицирует наши приложения, что очень полезно бизнесу и нам как разработчикам.
В ситуации, когда react или vue — разработчику придется поддерживать приложение на angular с использованием ngrx, ему будет намного проще разобраться в нем.
И он и компания благодарна за продукт такого качества. А это плюс в нашу карму :D
В следующих статьях перейдем, собственно, к примерам и особенностям модуля ngrx\store.
Можете подписаться, чтобы не пропустить следующие статьи и не забываем делать claps — так я буду знать, что материал оказался полезным для Вас!
