리덕스는 퍼브/서브 또는 옵서버 패턴으로 볼 수 있습니까?

리덕스는 퍼브/서브 또는 옵서버 패턴으로 볼 수 있습니까?

리액션.js, 즉 웹에서 몇 가지 튜토리얼을 마쳤습니다.

제가 본 비디오 튜토리얼의 일부인 redux는 완전히 처음입니다.자세히 알아볼수록 react.js의 초기 아이디어를 대체한다는 점에서 의미가 없어집니다.반응에서 구성요소는 워크플로우를 위에서 아래로 유지하기 위해 소품을 통해 전달될 수 있는 자체 상태를 가집니다.

redux를 사용하면 어플리케이션 상태 전체를 글로벌하게 만들고 그 (글로벌) 상태를 조작하기 위한 액션을 정의해야 합니다.그러면 일반적인 자바스크립트 pub/sub 또는 옵서버 패턴 이외의 액션은 무엇일까요?아니면 제가 잘못 알고 있는 걸까요? - 해명을 해주시면 감사하겠습니다.

Redx는 "react.js의 초기 아이디어를 대체하는" 것이 아니라 컴포넌트 간의 공유 상태를 관리하고 상태 돌연변이를 조정하는 라이브러리와 같다고 생각합니다.Redx는 실제로 pub/sub 패턴을 사용하고 있습니다.여기서 스토어 메서드를 참조해 주세요.http://redux.js.org/docs/api/Store.html#store-methods 를 참조해 주세요.subscribe상태 트리의 변경 사항을 구독하는 데 구성 요소가 사용하는 메서드입니다.으로 Store Store.subscribe)으로connect기본적으로) 이 기능을 제공합니다.실제 실장은 이쪽에서 확인하실 수 있습니다.추천은 그다지 복잡하지 않습니다(실제로 다른 Flux 실장에 비해 Redux의 주된 장점입니다).https://github.com/reduxjs/react-redux/blob/4.x/src/components/connect.js#L199

이 코드는 스토어에서 발생하는 변경에 가입하는 것 외에도 필요한 경우에만 구성요소에 새로운 소품을 전달(따라서 재렌더 트리거)하는 등 일부 최적화를 수행합니다.

또한 컴포넌트의 내부 상태를 Redux와 함께 계속 사용해도 문제가 없습니다.내부 상태를 사용하여 다른 컴포넌트와 공유하지 않거나 공유할 필요가 없는 상태를 저장할 수 있습니다.

보다 복잡한 애플리케이션을 사용하는 경우 서로 대화(액션)하고 상태를 공유해야 하는 최상위 컴포넌트를 사용하여 Redx와 같은 것이 필요하다는 것을 알 수 있습니다.

Redx의 액션은 기본적으로 POJO(일반적으로 오래된 Javascript 객체)일 뿐입니다.사용자가 트리거한 액션(예를 들어 버튼을 클릭)에 대응하여 자주 디스패치하는 이벤트라고 생각할 수 있습니다.단, 이에 한정되지 않고 원하는 장소에서 액션을 디스패치할 수 있습니다.Redux 스토어는 이러한 액션을 수신하고 사용자가 디스패치한 액션오브젝트를 통과하는 리듀서(순수 함수)를 호출합니다.

리듀서는 디스패치된 모든 액션을 대행 수신하여 자신이 관리하는 상태의 슬라이스에 대해 새로 업데이트된 상태를 반환할 수 있습니다.

그런 의미에서 리듀서는 액션을 처리하고 필요에 따라 상태를 갱신하는 기능입니다.

또한 리듀서가 상태의 새 복사본을 반환하여 상태를 업데이트하면 연결된 컴포넌트(상태 변경에 서브스크라이브됨)는 새로운 소품을 전달받고 변경을 반영하기 위해 다시 렌더링됩니다.

플레인 js 오브젝트만 디스패치하는 것만으로는 불충분할 수 있으며 제어가 더 필요할 수 있습니다.예를 들어 AJAX 콜로부터의 응답에 근거해 스테이트의 카운터를 갱신할 필요가 있는 경우 등, 보다 복잡한 로직을 실행할 필요가 있는 경우에, 이것이 명확해집니다.

redux-thunk를 사용하면 일반 객체가 아닌 기능을 디스패치할 수 있습니다.함수를 디스패치함으로써 제어 패턴의 반전을 매우 간단한 방법으로 효과적으로 구현할 수 있습니다.사용자의 액션은 POJO 액션처럼 단순한 스테이트먼트가 아니라 함수에 의해 기술되는 "레시피"가 됩니다.

는 " 사용"을 지원했을 액션에 는 기본 나 다른것이입니까? 조치의 경우 기본 Action 클래스 같은 것이 없는 이유는 무엇입니까?그럴 필요가 없기 때문입니다.「값의 이라고 하는한 오브젝트(기본적으로는 「됩니다).type속성만 있으면 됩니다.기본적으로 가장 심플한 인터페이스입니다.이것은, 실장이 아니고, 인터페이스(액션)에 대해서 프로그래밍 하는 것으로 간주할 수 있습니다.

각 컴포넌트가 자체 상태를 관리하는 것이 아니라 글로벌 상태가 더 나은 이유는 무엇입니까?주로 상태 관리가 사실 중요하지 않은 js 앱에서 가장 어려운 부분이기 때문입니다.Redx를 사용하면 UI 계층에서 모든 로직을 추출하여 테스트하기 쉬워집니다.실제로 단일 구성 요소를 렌더링하지 않고도 Redux 앱의 실제 "비즈니스 논리"를 모두 테스트할 수 있어야 합니다.

컴포넌트는 지시받은 대로 렌더링하기 때문에 '덤버'와 '순도'가 됩니다.여기서 "순수"란 어떤 상태도 유지하지 않기 때문에 렌더링되는 것은 특정 시점의 입력('프로폰' 읽기)에 따라 달라지며, 따라서 "상태 없음"을 의미합니다.

또한 상태를 단일 json 직렬화 가능 개체로 설정하면 디버깅, 스냅샷 생성 및 서버 또는 로컬 스토리지에서 전송/복원이 용이해집니다.

Fabios의 답변을 두 번 상향 투표할 수 없습니다.댓글 섹션은 너무 작습니다.

네, 제가 보기에는 펍/서브에서 컨벤션이 열리는 것 같아요.

소품을 물려주는 것이 얼마나 골칫거리인지 설명하기 위해, 여기 예가 있다.

현재 로그인한 사용자를 표시하는 구성 요소가 있다고 가정합니다.컴포넌트 계층은 거대한 트리와 같습니다.이 컴포넌트를 루트에서 시작하는 브랜치와 루트에서 시작하는 다른 브랜치(계층 내 깊은 곳)에서 각각 다른 경로로 루트 컴포넌트에서 리프 노드로 사용자 info를 전달해야 합니다.모든 컴포넌트의 소품을 오염시키는 방법(사용자의 정보와는 전혀 관련이 없지만 이제는 알아야 합니다).

언급URL : https://stackoverflow.com/questions/39977540/can-redux-be-seen-as-a-pub-sub-or-observer-pattern