Я полностью поддерживаю шаблон с избыточностью в приложениях Angular, так как он имеет следующие плюсы :
- Состояние пользовательского интерфейса отделено от вида
- Очень хорошо работает с архитектурой компонентов контейнера-представления
- Хорошо поддерживается сообществом
- состояние пользовательского интерфейса становится дополнительным инструментом отладки (в зависимости от вашего пристрастия)
При использовании в тандеме с компонентной архитектурой представления контейнера, redux является отличным выбором для масштабируемых приложений.
Но, как и у любой архитектуры, есть некоторые минусы :
- Шаблон редукса и неотъемлемое преимущество отсоединенного состояния пользовательского интерфейса не автоматически равняют организованный код.Хаосу так же легко править в моделях вашего магазина и в коммуникации между вашим магазином и компонентами.
- Вы, несомненно, слышали это много раз раньше: стандартный код.
- Естьнесколько вариантов редукса для Angular со своими причудами и сообществами.Если ваш вкус выходит из моды, вы застряли с редко поддерживаемой библиотекой или приложите много усилий, чтобы его отключить.
- Это сильно повлияет на архитектуру вашего приложения.Поэтому важно, чтобы все (или, по крайней мере, наиболее самоуверенные) разработчики в команде участвовали в этом.Некоторые люди просто не любят это.Это тоже хорошо, если они также предоставляют эквивалентное или лучшее (и конкретное) решение.
Отделенное состояние пользовательского интерфейса
Приложения Redux используют store для сохранения всех состояний пользовательского интерфейсак которым, в зависимости от архитектуры вашего компонента, могут обращаться определенные или все компоненты для обновления представления.Это, конечно, не означает, что вы не можете иметь состояние пользовательского интерфейса внутреннего компонента, которое исчезает при уничтожении компонента.
Разделив (таким образом) состояние (глобального) пользовательского интерфейса, вы можете использовать его по-разному, что вы чаще всего будете делать с помощью так называемых селекторов.Это аналогично использованию базы данных для получения всех данных, необходимых для выполнения запроса к серверу.
Компонентная архитектура контейнерного представления
Хотя это и не является частью шаблона избыточности, я бы осмелился сказатьчто шаблон с избыточностью приемлем в Angular только при использовании с шаблоном представления контейнера.
Контейнер: По сути, вы разделяете свое приложение на функциональные домены, каждый из которых получает так называемый «компонент контейнера».Для каждой функции это единственный компонент (с некоторыми неудачными исключениями), которому разрешено взаимодействовать с состоянием пользовательского интерфейса и другими зависимостями всего приложения (например, Router, ActivatedRoute).
Контейнерный компонент содержит всю бизнес-информацию.логика для вашего функционального домена и координирует связь между его отдельными компонентами представления и зависимостями всего приложения, такими как хранилище, маршрутизатор и сервисы.
К сожалению, иногда просто проще разместить контейнер под контейнером.Например, в дочерних маршрутах отправка данных через маршрутизатор-выход обычно не стоит усилий.
Презентация: Все остальные компоненты являются компонентами представления (немыми компонентами), которые ничего не знают оостальная часть вашего приложения.Чтобы настроить HTML-шаблон, они получают данные через свои @Inputs.Они также не должны (напрямую) вызывать какие-либо побочные эффекты за пределами их HTML-шаблона.Например, чтобы изменить состояние пользовательского интерфейса, он не отправляет действие напрямую в хранилище, а вместо этого информирует контейнер через @output о том, что что-то произошло, и контейнер решает, следует ли отправить действие.
Компонент представления также не вызывает никаких других побочных эффектов.Они всегда используют @outputs для информирования компонента контейнера, который решает, что делать с информацией.Например, ваша презентация отображает список супергероев.Когда пользователь нажимает на супергероя для получения дополнительной информации, ваша презентация не открывает новую страницу (она ничего не знает о страницах).Вместо этого он отправляет событие через свой @output с идентификатором супергероя в контейнер.Затем контейнер может открыть новую страницу, открыть всплывающее окно, обновить родственный компонент и т. Д. Таким образом, ваши компоненты презентации станут более надежными, более простыми в тестировании и более пригодными для повторного использования, в то время как состояние вашего интерфейса пользователя и другие побочные эффекты ограничены.к вашим компонентам контейнера.
Альтернатива - позволить каждому компоненту взаимодействовать с магазином или вызывать другие побочные эффекты - это анти-шаблон, который лишит вас преимуществ от разделения вашего пользовательского интерфейса.Это также означает, что у вас могут быть действия, выполняемые из любой точки вашего приложения.
Сообщество / Angular Redux Flavors
Существует большой интерес для шаблона редукса, не только для Angular иРеагируйте, но в родной iOS и Android, а также.В Angular есть несколько разновидностей избыточности, которые, кажется, обладают достаточным сцеплением, особенно ngrx / store.
Понятия избыточности в Angular немного отличаются от React.Например, redux-thunk - это библиотека реагирования, и в angular нет абсолютно одинаковых (обратите внимание, если это неверно).В ngrx / store действия обрабатываются внутри эффекта и с использованием наблюдаемых, что может потребовать некоторого привыкания.Кроме того, объединение нескольких эффектов может быть необходимо для достижения того же результата, что и для избыточного потока.
Что касается редукционных ароматов в угловых выражениях, то некоторые из самых популярных:
- ngrx / store
- ngxs / store
- akita
Мертвый или более не в хорошем состоянии:
- angular-redux (к сожалению)
Состояние пользовательского интерфейса в качестве средства отладки
ngrx / store (по крайней мере) предлагает использовать расширение Chrome Redux DevTools.Это отличный инструмент для проверки вашего магазина редуксов и того, как он менялся каждый раз, когда отправлялось действие.
Boilerplate
Когда вы используете избыточный код в необработанном виде, вы будете много писатьшаблонного кода.Это можно уменьшить несколькими способами:
- Напишите свои собственные фабрики.Например, напишите заводскую функцию для действий, которая возвращает объект с четырьмя действиями: загрузка, успех, ошибка, сброс.Соответственно создайте фабрики эффектов и редукторов, которые все будут обрабатывать шаблон избыточности определенным образом.
- ngrx имеет свой собственный вариант объектов избыточности, которые сокращают шаблонный код таким же образом, как и в подходе «накатить свой собственный» выше
- ngrx недавно внедрил библиотеку ngrx / data, которая еще больше абстрагирует некоторые вещи в лексизме, чтобы фактически устранить необходимость в шаблонном коде
Организованный код
Как уже упоминалось выше,Ваш магазин может очень быстро дезорганизоваться по мере роста приложения.Часто мы думаем о магазине как о зеркале представления и определяем наш магазин на основе первого построенного представления.Затем мы получаем множество дубликатов в магазине, которые необходимо реорганизовать.
Вместо того, чтобы отступить от каждого конкретного представления, чтобы взглянуть на состояние пользовательского интерфейса, требуемого для нескольких представлений, и, по крайней мере, частично нормализовать хранилище, вы можете опираться на селекторы, чтобы составить состояние пользовательского интерфейса, которое каждое представлениеneeds.
В отличие от Redux в React, можно иметь отдельные хранилища, разделяя их на функциональные модули.Хотя на первый взгляд это кажется хорошей идеей, она часто приводит к проблемам, когда вам нужно делить состояние между модулями, особенно если у вас ленивые модули.В конце концов, обычно это не стоит проблем, поэтому я рекомендую начинать с одного магазина на уровне модуля приложения, пока не возникнет необходимость разделить магазин.