В чем реальная разница между редуксом и конечным автоматом (например, xstate)?

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

• Redux — это, по сути, контейнер состояния, в котором события (называемые actions в Redux) отправляются редюсеру, который обновляет состояние.
• XState также является контейнером состояния, но он отделяет конечное состояние (например, "loading", "success") от «бесконечного состояния» или контекста (например, items: [...]).
• Redux не диктует, как вы определяете свои редукторы. Это простые функции, которые возвращают следующее состояние с учетом текущего состояния и события (действия).
• XState — это «редуктор с правилами» — вы определяете легальные переходы между конечными состояниями из-за событий, а также какие действия должны выполняться при переходе (или при входе/выходе из состояния)
• В Redux нет встроенного способа обработки побочных эффектов. Есть много вариантов сообщества, таких как redux-thunk, redux-saga и т. д.
• XState делает действия (побочные эффекты) декларативными и явными — они являются частью объекта State, который возвращается при каждом переходе (текущее состояние + событие).
• В настоящее время Redux не имеет возможности визуализировать переходы между состояниями, поскольку не различает конечное и бесконечное состояния.
• В XState есть визуализатор: https://statecharts.github.io/xstate-viz, который выполним. в силу декларативного характера.
• Неявная логика/поведение, представленное в редукторах Redux, не может быть декларативно сериализована (например, в JSON).
• Определения компьютеров XState, которые представляют логику/поведение, могут быть сериализованы в JSON и считаны из JSON. Это делает поведение очень переносимым и настраиваемым с помощью внешних инструментов.
• Redux не является строго конечным автоматом.
• XState строго придерживается спецификации W3C SCXML: https://www.w3.org/TR/scxml/< /а>
• Redux полагается на то, что разработчик вручную предотвращает невозможные состояния.
• XState использует диаграммы состояний для естественного определения границ обработки событий, что предотвращает невозможные состояния и может подвергаться статическому анализу.
• Redux поощряет использование единого «глобального» атомарного хранилища.
• XState поощряет использование подхода, подобного модели актера, где может быть много иерархических экземпляров диаграммы состояний/«сервиса», которые взаимодействуют друг с другом.

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

Помните, что с конечными автоматами, если по какой-то причине (зависимость от внешнего API и т. д.) есть вероятность, что приложение может быть заблокировано в состоянии, в котором оно не может перейти в другое состояние из-за ограничений, вы должны решить это.

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

С другой стороны, Redux — это фреймворк однонаправленной архитектуры. Однонаправленные архитектуры заставляют вас иметь одно направление потока данных. В Redux он начинается с User->View->(Action)->Store->Reducer->(Middleware)->Store->(State)->View. Как и в случае с конечными автоматами, вы можете запускать побочные эффекты с помощью ПО промежуточного слоя в Redux. Вы можете ограничить/запретить переходы между состояниями, если хотите. В отличие от конечного автомата, Redux обеспечивает однонаправленный поток данных, чистый! функции редуктора, неизменяемые объекты состояния, одно наблюдаемое состояние приложения.

несколько моих пунктов ниже.

• Состояние пользовательского интерфейса и состояние бизнеса/бэкенда объединены в Redux. Из-за этого каждое обновление пользовательского интерфейса или бизнес-состояния создает обновление данных в хранилище избыточности.
• Xstate разделяет состояние пользовательского интерфейса и состояние серверной части.
• В редуксе все узлы присутствуют внутри корневого узла. Xstate децентрализует и распределяет данные внутри независимых механизмов.
• Приложение может переходить только между уже определенными состояниями. Таким образом, любая ошибка или ошибка может быть исправлена ​​в самом движке.
• Внутренние состояния управляются самим движком в Xstate. Redux представляет новые состояния в виде флагов.
• Агонизм рендерера — сохранение как можно большей части состояния в машинах, и, если нам нужно, мы можем относительно легко переключать фреймворки рендеринга (например, с react на vue).
• Contexts предоставляет конкретный класс для представления единого интерфейса для внешнего мира.