redux와 상태 기계(예: xstate)의 실제 차이는 무엇입니까?

redux와 상태 기계(예: xstate)의 실제 차이는 무엇입니까?

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

우리는 추가적인 리팩토링의 범위 내에서 이 애플리케이션을 위한 일종의 상태 컨테이너를 구현할 필요가 있다고 결정했습니다.이전에 redux와 ngrx store(실제로는 동일한 원칙을 따르는)에 대한 경험이 있었습니다.

Redux는 우리에게 선택 사항이지만, 개발자 중 한 명이 상태 기계 기반 라이브러리, 특히 xstate 라이브러리를 사용할 것을 제안했습니다.

저는 xstate와 함께 일해본 적이 없어서 흥미롭게 생각하여 설명서를 읽고 다양한 예시를 보기 시작했습니다.유망하고 강력해 보였지만 어느 순간 저는 그것과 리덕스 사이에 큰 차이가 없다는 것을 이해했습니다.

저는 답을 찾거나 xstate와 redux를 비교하는 다른 정보를 찾기 위해 몇 시간 동안 노력했습니다."redux에서 상태 머신으로 이동"과 같은 일부 기사나 redux와 xstate를 함께 사용하는 데 초점을 맞춘 라이브러리 링크(상당히 이상함) 외에는 명확한 정보를 찾을 수 없었습니다.

다른 점을 설명하거나 개발자가 언제 xstate를 선택해야 하는지 알려줄 수 있다면 기꺼이 도와드리겠습니다.

XState를 만들었지만 하나를 사용할지 여부는 팀에 따라 다릅니다.대신 몇 가지 주요 차이점을 강조해 보겠습니다.

리덕스	X주
기본적으로 이벤트(Redux에서 액션이라고 함)가 업데이트 상태를 나타내는 축소기로 전송되는 상태 컨테이너	또한 상태 컨테이너이지만 유한 상태를 구분합니다(예:"loading","success"infinite 상태 또는 컨텍스트(예:items: [...])
축소기를 정의하는 방법을 지정하지 않습니다. 현재 상태 및 이벤트(동작)가 지정된 다음 상태를 반환하는 일반 함수입니다.	"규칙이 있는 축소기" - 사건으로 인한 유한한 상태 간의 법적 전환을 정의하고 전환(또는 상태에서 진입/exit 시)에 수행해야 하는 작업을 정의합니다.
사이드 effects를 처리할 수 있는 기본 제공 방식이 없습니다. redux-thunk, redux-saga 등 다양한 커뮤니티 옵션이 있습니다.	조치(측면 effects)를 선언적이고 명시적으로 만듭니다 - 그것들은 일부입니다.State각 전환 시 반환되는 개체(현재 상태 + 이벤트)
유한한 상태와 무한한 상태를 구분하지 않기 때문에 현재 상태 간의 전이를 시각화할 방법이 없습니다.	visualizer: https://statecharts.github.io/xstate-viz 이 있습니다. 이는 선언적 특성으로 인해 가능합니다.
축소기로 표현되는 암시적 논리/행동은 선언적으로 직렬화될 수 없습니다(예: JSON).	논리/행동을 나타내는 기계 정의는 JSON으로 직렬화되고 JSON에서 읽을 수 있습니다. 이는 동작을 매우 휴대성 있게 만들고 외부 도구에 의해 구성할 수 있게 만듭니다.
엄밀하게 국가의 기계가 아닌	W3C SCXML 사양을 철저히 준수합니다. https://www.w3.org/TR/scxml/
불가능한 상태를 수동으로 방지하기 위해 개발자에게 의존합니다.	상태 관리도를 사용하여 이벤트를 처리하기 위한 경계를 자연스럽게 정의하므로 불가능한 상태를 방지하고 정적으로 분석할 수 있습니다.
"세계적인" 단일 원자 저장소의 사용을 장려합니다.	서로 의사소통하는 계층적 상태도/"서비스" 인스턴스가 많이 존재할 수 있는 Actor-model 방식의 사용을 장려합니다.

저는 이번 주에 문서에 주요 차이점들을 더 추가하겠습니다.

상태 머신은 단방향 데이터 흐름을 갖도록 지시(강제)하지 않습니다.데이터 흐름과는 무관합니다.그것은 상태 변화를 제한하고 상태 전환에 관한 것입니다.따라서 일반적으로 애플리케이션의 일부 부분만 상태 머신으로 설계되며, 일부 상태 변경을 제한/금지해야 하고 전환에 관심이 있는 경우에만 해당됩니다.

상태 기계에서는 어떤 이유로 (외부 API 의존성 등) 앱이 제약으로 인해 다른 상태로 전환할 수 없는 상태로 잠길 가능성이 있으므로 이를 해결해야 합니다.

그러나 상태 전환 대신 마지막 앱 상태 자체에만 관심이 있고 상태 제약이 중요하지 않은 경우 상태 기계를 사용하지 않고 상태 자체를 직접 업데이트하는 것이 좋습니다(Action classs를 통해 Singleton class 업데이트에서 상태 랩을 수행할 수 있음).

---

반면에 Redux는 단방향 아키텍처 프레임워크입니다.단방향 아키텍처로 인해 데이터 흐름의 방향성이 단일화됩니다.Redux에서는 다음과 같이 시작합니다.User->View->(Action)->Store->Reducer->(Middleware)->Store->(State)->View. 상태 기계와 마찬가지로 Redux의 미들웨어로 부작용을 유발할 수 있습니다.필요한 경우 상태 전환을 제한/금지할 수 있습니다.Redux는 상태 머신과는 다르게 단방향 데이터 흐름, pure!reducer 함수, 불변 상태 객체, 단일 관찰 가능한 앱 상태를 강제합니다.

아래의 나의 요점들은 거의 없습니다.

• UI 상태와 비즈니스/백엔드 상태는 Redux에서 함께 연결됩니다.이 때문에 UI 또는 비즈니스 상태에 대한 모든 업데이트는 리덕스 저장소에 데이터 업데이트를 생성합니다.
• Xstate는 UI 상태와 백엔드 상태를 분리합니다.
• Reductu에서 모든 노드는 루트 노드 내부에 존재합니다.Xstate는 독립적인 머신 내부의 데이터를 분산하고 배포합니다.
• 응용프로그램은 이미 정의된 상태 간에만 전환할 수 있습니다.따라서 기계 자체에서 오류나 버그를 수정할 수 있습니다.
• 내부 상태는 Xstate에서 Machine 자체에서 관리합니다.축소판은 새 상태를 플래그로 나타냅니다.
• 렌더러 애그너티브 - 상태의 많은 부분을 기계로 올려 유지하고 필요한 경우 렌더링 프레임워크를 비교적 쉽게 전환할 수 있습니다(예: 반응에서 vue로).
• 컨텍스트는 외부 세계에 단일 인터페이스를 제공하는 구체적인 클래스를 제공합니다.

언급URL : https://stackoverflow.com/questions/54482695/what-is-an-actual-difference-between-redux-and-a-state-machine-e-g-xstate