Цель этой статьи — поделиться шаблоном для управления логикой ветвления состояний в вашем компоненте.
В разработке внешнего интерфейса одним из распространенных случаев является переключение другого пользовательского интерфейса или поведения в зависимости от другого статуса. Например:
- На странице кампании отображается разный пользовательский интерфейс в зависимости от статуса кампании, статуса входа и т. д..
- Компонент продукта отображается по-разному в зависимости от статуса продукта, статуса проверки, статуса нарушения и т. д.
Если мы не будем обращаться с этим осторожно, это приведет к сложной логике в нашем коде. Его будет сложнее поддерживать, и он будет подвержен ошибкам.
Чтобы смягчить его, мы можем использовать следующие 2 подхода:
Табличные методы
Это метод программирования из книги Code Complete для более лаконичного (иногда) управления логикой ветвления if else.
Давайте посмотрим на пример:
Хотя второй подход имеет повторяющееся объявление action3. В этом случае все еще проще. Но имейте в виду, что если у вас есть только несколько действий с кучей состояний, подход на основе таблиц может быть довольно избыточным и многословным. Мы должны найти баланс того, когда что использовать.
Вот простой инструмент для создания такого JS-кода, управляемого таблицами, вы можете взглянуть на него. Не стесняйтесь высказывать свое мнение об этом инструменте :)
https://playground.kenneth.pro/easy-state
Шаблон состояния
Насколько я понимаю, основная идея шаблона состояния GOF заключается в следующем:
Сначала выберите предопределенный набор методов и переменных по заданному состоянию и предоставьте тот же интерфейс, чтобы его зависимые могли использовать интерфейс, не зная деталей.
Если мы используем шаблон состояния, реализация будет такой:
- Предварительное определение всех переменных и методов, которые нужно переключать в самом начале, и выбирать набор по заданному состоянию.
Давайте посмотрим на реальный пример в Typescript в сочетании с табличным методом, о котором мы только что говорили.
В этом примере CampaignComponent отображает другой пользовательский интерфейс на основе разных LoginStatus, CampaignStatus, UserCampaignStatus:
В этом примере, несмотря на то, что часть ветки состояния является избыточной и многословной, она отделяет бизнес-логику от вашего компонента пользовательского интерфейса. Это как-то более тестируемо и ремонтопригодно.
Возьмите React в качестве примера, мы можем подготовить наши реквизиты в наших пользовательских хуках или редукционных контейнерах.
Кроме того, вы можете обернуть объект States в функцию, чтобы сделать его более простым или менее подробным для заданных бизнес-потребностей, например
Пока код понятен, тестируем, непротиворечив и работает правильно. Неважно, какую парадигму мы используем. Это хороший код, с которым может работать каждый.
Надеюсь, этот пост поможет вам более или менее, удачной разработки!
