redux와 상태 머신 (예 : xstate)의 실제 차이점은 무엇입니까?

저는 중간 복잡성의 한 프런트 엔드 애플리케이션을 조사하고 있습니다. 현재 순수 자바 스크립트로 작성되었으며이 애플리케이션의 몇 가지 주요 부분을 연결하는 다양한 이벤트 기반 메시지가 있습니다.

우리는 추가 리팩토링의 범위에서이 애플리케이션에 대한 일종의 상태 컨테이너를 구현해야한다고 결정했습니다. 이전에는 redux 및 ngrx 저장소에 대한 경험이있었습니다 (실제로 동일한 원칙을 따릅니다).

Redux 는 우리에게 옵션이지만, 개발자 중 한 명이 상태 머신 기반 라이브러리, 특히 xstate 라이브러리 사용을 제안했습니다 .

저는 xstate로 작업 한 적이 없어서 흥미롭고 문서를 읽고 다른 예제를보기 시작했습니다. 유망하고 강력 해 보였지만 어느 시점에서 나는 그것과 redux 사이에 큰 차이가 없다는 것을 이해했습니다.

나는 xstate와 redux를 비교하는 대답이나 다른 정보를 찾으려고 몇 시간을 보냈습니다. "get from redux to a state machine" 과 같은 일부 기사 나 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. State Machines와 마찬가지로 Redux에서 미들웨어로 부작용을 유발할 수 있습니다. 원하는 경우 상태 전환을 제한 / 금지 할 수 있습니다. 상태 머신과는 달리 , 돌아 오는 단방향 데이터 흐름을 강제로 순수한 ! 감속기 함수, 불변 상태 객체, 관찰 가능한 단일 앱 상태.