В настоящее время я создаю SPA в react, который предназначен для работы исключительно на конечных автоматах. Основными мотивами для этого являются следующие:
- для упрощения процесса проектирования как для дизайнеров, так и для разработчиков
- для обеспечения детерминизма во всем приложении (меньше ошибок)
- для легкого создания снимка приложения состояние (идеально подходит для точного определения явное ошибки)
- для простого создания снимка приложения история (идеально подходит для поиска, где неявные ошибки случаются - например, сбои пользовательского интерфейса)
Я также стараюсь не зависеть от состояния и проблем пользовательского интерфейса, чтобы разработчики могли работать над обоими одновременно без помех.
Обычно конечные автоматы локализуются (и управляются внутри) определенным объектом. Например, Timer может управлять своим собственным состоянием (например, paused / running / и т. Д.). Это хорошо для относительно простых машин, однако, когда мы рассматриваем создание единой иерархической машины для всего приложения, этот подход (по понятным причинам) не работает.
Кроме того, если мы хотим, чтобы одна машина представляла все наше приложение, эта машина должна быть способна обрабатывать любые динамические аспекты приложения. Например, представьте, что пользователь проводит какой-то экзамен. Этот экзамен получен с сервера с неизвестным количеством / типами вопросов. Конечный автомат должен быть способен динамически создавать новые ветви состояний для каждого из выбранных вопросов, причем тип ветви состояния определяется типом вопроса.
Я видел несколько библиотек конечных автоматов для JS, однако ни одна из них не способна обрабатывать динамические / динамические создания состояний.
Я начал создавать свою собственную реализацию в redux (см. мой другой вопрос ), но в конечном итоге мне пришлось отказаться от него из-за несовместимости в способах обработки событий, связанных с избыточностью и конечным автоматом.
После нескольких недель попыток написать независимую библиотеку я вернулся сюда, надеясь, что вы, ребята, сможете пролить свет на то, как лучше всего это сделать.
Я думаю, что самое большое препятствие для меня сводится к поддержанию определенного уровня «качества» (то есть обеспечения минимального перекрытия между состояниями и пользовательским интерфейсом, поддержания простоты API и обеспечения его общей работы с большинством структур пользовательского интерфейса - в случае, если мы переместимся от react в будущем).