Повысьте эффективность своей реакции с помощью конечных автоматов

Сочетание React и конечных автоматов - отличный рост производительности для вас как разработчика. Это также улучшает обычно шаткое сотрудничество разработчиков и дизайнеров.

Концепция конечного автомата очень проста: компонент может находиться в одном состоянии за раз и иметь конечное число состояний.

Как вы говорите, насколько это полезно для разработки пользовательского интерфейса?

Эта проблема

Давайте рассмотрим простой компонент текстовой редакции, такой как очень неудачно оформленный ниже:

Возможные «состояния» такого компонента (слева направо):

  • Отображаемое значение
  • Изменить значение
  • Сохранение в процессе
  • Ошибка сохранения

Простая форма для модели компонента имеет 5 свойств:

Правильные комбинации свойств дадут нам 4 состояния, которые мы определили выше.

Проблема в том, что на самом деле существует 2⁵ = 32 возможных комбинации для состояния. Это означает, что существует 28 неправильных способов использования свойств состояния.

Одна из типичных ошибок вышеупомянутого компонента - не сбрасывать ошибку после успешного сохранения. Таким образом, конечный пользователь сохранит, получит сообщение об ошибке “Something went wrong”, исправит ошибку, снова сохранит и перейдет в режим отображения. Все идет нормально. За исключением повторного перехода в режим редактирования… сообщение об ошибке все еще существует. Правдивая история. Я несколько раз видел, как это делают неопытные разработчики.

Наш компонент настолько прост, насколько это возможно, и все же он демонстрирует печальную правду:

Работа со свойствами необработанного состояния означает, что надежность компонента зависит исключительно от правильного использования свойств, что означает… для каждого разработчика, изменяющего код… на протяжении всего жизненного цикла проекта.

Все мы знаем, чем это заканчивается!

Решение

Рассмотрим другой подход с использованием «конечных автоматов». Состояния будут:

Это более подробный, чем первый подход, но он дает много преимуществ:

  • Все состояния компонента можно увидеть, просто взглянув на конечный автомат. Состояния имеют логические имена, и использование каждого необработанного свойства документируется самостоятельно. Новые разработчики в команде сразу почувствуют себя как дома.
  • Соглашение о том, как расширить компонент, ясное: создать новое состояние и соответствующим образом установить необработанные свойства. Никто в здравом уме не осмелится использовать raw setState(), когда в компоненте реализован конечный автомат.
  • И последнее, но не менее важное: процесс передачи с командой UI / UX становится максимально гладким. Вам нужен визуальный дизайн для каждого состояния вашей машины и, возможно, несколько анимаций для переходов. Вот и все. Ясный и легко отслеживаемый.

Минималистичная рабочая версия приведенного выше примера будет:

Использование:

При использовании конечных автоматов нужно написать небольшой шаблонный код:

  • Создайте служебный метод, который устанавливает имя и содержимое состояния. Следите за текущим именем состояния, чтобы упростить отладку.
  • Сохраняйте метод, который генерирует ваше состояние, чистым и используйте его для инициализации вашего состояния в конструкторе.
  • Уничтожьте this.state.machine вместо this.state в вашем методе рендеринга
  • Государству могут потребоваться параметры, с которыми может быть трудно справиться. Как показывает опыт, если для генерации вашего состояния требуется более 3 параметров, то ваш компонент не должен использовать шаблон конечного автомата.

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

Заключение

Шаблон конечного автомата - это хороший способ улучшить читаемость компонентов пользовательского интерфейса и улучшить процесс разработки от визуального дизайна до обслуживания.

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

Тем не менее, используйте шаблон в своей библиотеке стандартных / базовых компонентов! Это та часть приложения, которая проживет дольше всего. В конце концов, каждый разработчик в команде прикоснется к нему и получит пользу от руководства и надежности, обеспечиваемых конечным автоматом.

Спасибо за прочтение!