Управление состоянием в Angular 2 Apps с помощью ngrx / store было рецензировано Себастьяном Зейтцем , Марком Брауном и Вильданом Софтиком . Спасибо всем рецензентам SitePoint за то, что сделали контент SitePoint как можно лучше!
Компоненты, которые мы создаем для наших веб-приложений, часто содержат состояние. Соединение компонентов может привести к совместному использованию изменяемого состояния: это сложно управлять и приводит к несогласованности. Что если у нас есть одно место, где мы изменяем состояние и позволяем сообщениям делать все остальное? ngrx / store — это реализация Redux для Angular, использующая RxJS, которая привносит этот мощный паттерн в мир Angular.
В этой статье я расскажу о проблеме общего изменяемого состояния и покажу, как вы можете решить эту проблему с помощью библиотеки ngrx / store, чтобы привнести одностороннюю архитектуру потока данных в ваши приложения Angular 2. Попутно мы создадим пример приложения, которое позволит пользователю искать видео с помощью API YouTube.
Примечание. Вы можете найти код, сопровождающий эту статью, в этом репозитории GitHub .
Проблема с параллелизмом
Создание компонентов, которые взаимодействуют друг с другом, является типичной задачей с участием государства. Нам часто приходится идти в ногу со временем, когда разные компоненты Angular взаимодействуют с одним и тем же состоянием: когда несколько компонентов обращаются к этому состоянию и изменяют его, мы называем его разделяемым изменяемым состоянием .
Чтобы понять, почему общее изменяемое состояние представляет проблему, подумайте о компьютере, который используется двумя разными пользователями. Однажды первый пользователь обновит операционную систему до последней версии. Второй пользователь включает компьютер один день спустя и озадачен, поскольку интерфейс пользователя изменился без видимой причины. Это произошло потому, что два пользователя могли изменять один и тот же объект (в данном случае компьютер), не разговаривая друг с другом.
Общее изменяемое состояние на практике
Типичным примером общего состояния является набор свойств выполняемого нами действия. Если мы выполняем поиск в базе данных, мы называем этот набор функций текущим поиском . Отныне я буду называть такой набор поисковым объектом .
Представьте себе страницу, которая позволяет вам искать что-то по имени, а также предлагает возможность ограничить поиск по географическому положению. На этой странице будет как минимум два разных компонента, которые могут изменять текущие свойства поиска. Скорее всего, будет служба, отвечающая за фактический поиск.
Правила будут:
- если поле имени пустое, очистить результаты поиска
- если определено только имя, выполните поиск по имени
- если указаны имя и местоположение, выполните поиск по имени и местоположению
- для поиска по местоположению необходимо указать координаты (широта / долгота) и радиус
Доступные подходы
Одним из способов решения проблемы общего изменяемого состояния может быть переадресация объекта поиска назад и вперед между компонентами и службой, позволяя каждому изменять его.
Это повлечет за собой более подробное и сложное тестирование, которое отнимает много времени и подвержено ошибкам: для каждого теста вам нужно будет смоделировать объект, изменив только некоторые свойства, чтобы протестировать только определенное поведение. Все эти тесты и макеты также должны быть сохранены.
Кроме того, каждый компонент, взаимодействующий с состоянием, должен будет разместить логику для этого. Это ухудшает возможность повторного использования компонентов и нарушает принцип СУХОГО .