Яка фактична різниця між redux та автоматом стану (наприклад, xstate)?

Я працюю над дослідженням одного інтерфейсного додатку середньої складності. На даний момент він написаний на чистому javascript, у ньому багато різних повідомлень на основі подій, що з'єднують декілька основних частин цього додатка.

Ми вирішили, що нам потрібно застосувати якийсь державний контейнер для цього додатка для подальшого рефакторингу. Раніше я мав певний досвід роботи з redux та ngrx store (який насправді дотримується тих самих принципів).

Redux є варіантом для нас, але один із розробників запропонував використовувати бібліотеку на базі автомата, зокрема бібліотеку xstate .

Я ніколи не працював з xstate, тому мені це було цікаво і я почав читати документацію та переглядати різні приклади. Виглядав багатообіцяючим і потужним, але в якийсь момент я зрозумів, що не бачу суттєвої різниці між ним та редукцією.

Я годинами намагався знайти відповідь або будь-яку іншу інформацію, порівнюючи xstate та redux. Я не знайшов жодної чіткої інформації, крім деяких статей на зразок "перейти від redux до стану машини" або посилань на бібліотеки, орієнтованих на спільне використання redux і xstate (досить дивно).

Якщо хтось може описати різницю або сказати мені, коли розробники повинні вибрати xstate - запрошуємо вас.

Я створив XState, але я не збираюся казати вам, чи слід використовувати один за іншим; це залежить від вашої команди. Натомість я спробую виділити деякі ключові відмінності.

• Redux - це, по суті, контейнер стану, де події ( у 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 через Класи дій ).

З іншого боку, Redux - це односпрямована структура архітектури . Однонаправлені архітектури змушують вас мати єдиний напрямок потоку даних. У Redux це починається з User->View->(Action)->Store->Reducer->(Middleware)->Store->(State)->View. Як і державні машини, ви можете викликати побічні ефекти за допомогою Middlewares у Redux. Якщо ви хочете, ви можете обмежити / заборонити переходи штатів. На відміну від державної машини , Redux забезпечує односпрямований потік даних, чисто ! функції редуктора, незмінні об'єкти стану, один спостережуваний стан програми.