Facebook Flux보다 Redux를 사용하는 이유

질문 : Facebook Flux보다 Redux를 사용하는 이유는 무엇입니까?

---

나는 이 답변을 읽고 상용구를 줄이고 GitHub 예제를 몇 개 살펴보고 redux를 조금 시도했습니다 (todo 앱).

내가 이해하는 바와 같이 공식 redux 문서 동기 는 기존 MVC 아키텍처에 비해 전문가를 제공합니다. 그러나 질문에 대한 답을 제공하지 않습니다.

Facebook Flux보다 Redux를 사용해야하는 이유는 무엇입니까?

그것은 프로그래밍 스타일의 문제 일뿐입니다 : 기능적 대 비 기능적? 아니면 문제는 redux 접근 방식을 따르는 능력 / 개발 도구에 있습니까? 어쩌면 스케일링? 아니면 테스트?

redux가 기능적 언어에서 온 사람들에게 플럭스라고 말하면 맞습니까?

이 질문에 답하기 위해 플럭스와 redux에서 구현 redux의 동기 부여 포인트의 복잡성을 비교할 수 있습니다.

공식 redux doc 동기의 동기 부여 포인트는 다음과 같습니다.

답변

---

여기 Redux 작성자!

돌아 오는 플럭스에서 해당 다르지 않다. 전체적으로 동일한 아키텍처를 가지고 있지만 Redux는 Flux가 콜백 등록을 사용하는 기능적 구성을 사용하여 복잡성을 줄일 수 있습니다.

Redux에는 근본적인 차이가 없지만 Flux에서 구현하기 어렵거나 불가능한 특정 추상화를 더 쉽게 만들거나 적어도 구현할 수 있습니다.

예를 들어 페이지 매김을 사용하십시오. 내 Flux + React Router 예제 는 페이지 매김을 처리하지만 코드는 끔찍합니다. 끔찍한 이유 중 하나는 Flux가 매장에서 기능을 재사용하는 것을 부 자연스럽게 만든다는 것입니다. 두 개의 저장소가 서로 다른 작업에 대한 응답으로 페이지 매김을 처리해야하는 경우 공통 기본 저장소에서 상속하거나 (나쁜! 상속을 사용할 때 특정 디자인에 고정되어 있음) 내부에서 외부 적으로 정의 된 함수를 호출해야합니다. Flux 스토어의 비공개 상태에서 어떻게 든 작동해야하는 이벤트 핸들러. 모든 것이 지저분합니다 (확실히 가능한 영역에 있음).

반면에 Redux에서는 리듀서 구성 덕분에 페이지 매김이 자연 스럽습니다. 이것은 감속기이므로 페이지 매김 감속기를 생성 하는 감속기 팩토리를 작성한 다음 감속기 트리에서 사용할 수 있습니다 . 이것이 왜 그렇게 쉬운 지에 대한 핵심 은 Flux에서는 저장소가 평평하지만 Redux에서는 React 구성 요소가 중첩 될 수있는 것처럼 리듀서가 기능적 구성을 통해 중첩 될 수 있기 때문입니다.

이 패턴은 또한 사용자 코드가없는 실행 취소 / 다시 실행 과 같은 멋진 기능을 가능하게합니다. Undo / Redo를 Flux 앱에 두 줄의 코드로 연결하는 것을 상상할 수 있습니까? 거의. Redux를 사용하면 다시 한 번 리듀서 구성 패턴 덕분입니다. 나는 그것에 대해 새로운 것이 없다는 것을 강조 할 필요가 있습니다. 이것은 Flux의 영향을받은 Elm Architecture에서 개척하고 자세히 설명하는 패턴입니다.

사람들은 Flux를 사용하여 서버에서 잘 렌더링했지만, 각각 서버 렌더링을 "더 쉽게"만들려고 시도하는 20 개의 Flux 라이브러리가 있다는 것을 알았습니다. 아마도 Flux는 서버에 약간의 가장자리가있을 것입니다. 사실 페이스 북은 서버 렌더링을 많이하지 않기 때문에 그다지 걱정하지 않고 생태계에 의존하여 더 쉽게 만듭니다.

전통적인 Flux에서 스토어는 싱글 톤입니다. 즉, 서버에서 서로 다른 요청에 대해 데이터를 분리하기가 어렵습니다. 불가능하지는 않지만 어렵습니다. 이것이 대부분의 Flux 라이브러리 (및 새로운 Flux Utils )가 이제 싱글 톤 대신 클래스를 사용하도록 제안하여 요청 당 저장소를 인스턴스화 할 수있는 이유입니다.

Flux에서 해결해야 할 다음과 같은 문제가 여전히 있습니다 (자신이나 Flummox 또는 Alt 와 같은 좋아하는 Flux 라이브러리의 도움을 받아) :

• 저장소가 클래스 인 경우 요청 당 디스패처를 사용하여 어떻게 만들고 삭제합니까? 상점은 언제 등록합니까?
• 상점에서 데이터를 수화하고 나중에 클라이언트에서 다시 수화하는 방법은 무엇입니까? 이를 위해 특별한 방법을 구현해야합니까?

분명히 Flux 프레임 워크 (바닐라 Flux가 아님)는 이러한 문제에 대한 해결책을 가지고 있지만 너무 복잡합니다. 예를 들어 Flummox는 상점에서 serialize() 및 deserialize() 를 구현하도록 요청합니다 . Alt는 JSON 트리에서 상태를 자동으로 직렬화 takeSnapshot() 을 제공하여이 문제를 해결합니다.

Redux는 더 나아갑니다. (많은 감속기에 의해 관리되는) 하나의 저장소 만 있기 때문에 (재) 수화를 관리하는 데 특별한 API가 필요하지 않습니다. 상점을 "플러시"하거나 "수화"할 필요가 없습니다. 하나의 상점 만 있으면 현재 상태를 읽거나 새 상태로 새 상점을 만들 수 있습니다. 각 요청은 별도의 저장소 인스턴스를 가져옵니다. Redux를 사용한 서버 렌더링에 대해 자세히 알아보십시오.

다시 말하지만 이것은 Flux와 Redux에서 모두 가능한 경우이지만 Flux 라이브러리는 수많은 API와 규칙을 도입하여이 문제를 해결하고 Redux는 문제가 없기 때문에 해결할 필요조차 없습니다. 개념적 단순성 덕분에 1 위를 차지했습니다.

실제로 Redux가 인기있는 Flux 라이브러리가 될 의도는 없었습니다. 시간 여행과 함께 핫 리로딩에 대한 ReactEurope 토크 작업을 할 때 작성했습니다. 저는 한 가지 주요 목표가있었습니다 . 즉석에서 리듀서 코드를 변경하거나 액션을 생략하여 "과거를 변경"하고 상태가 재 계산되는 것을 확인하는 것입니다.

이 작업을 수행 할 수있는 단일 Flux 라이브러리는 본 적이 없습니다. React Hot Loader는이 작업을 허용하지 않습니다. 사실 Flux 스토어를 편집하면 어떻게해야할지 모르기 때문에 실패합니다.

Redux가 감속기 코드를 다시로드해야 할 때 replaceReducer() 호출하고 앱이 새 코드로 실행됩니다. Flux에서는 데이터와 함수가 Flux 스토어에 얽혀 있기 때문에 "함수 만 교체"할 수 없습니다. 또한 Dispatcher에 새 버전을 어떻게 든 다시 등록해야합니다. Redux에는없는 것입니다.

Redux는 풍부하고 빠르게 성장하는 생태계를 가지고 있습니다. 이는 미들웨어 와 같은 몇 가지 확장 점을 제공하기 때문입니다. 그것은 logging , Promises 지원, Observables , routing , immutability dev checks , persistence 등과 같은 사용 사례를 염두에두고 설계되었습니다. 이 모든 것이 유용하지는 않지만 쉽게 결합하여 함께 작업 할 수있는 도구 세트에 액세스 할 수 있다는 점이 좋습니다.

Redux는 Flux의 모든 이점 (작업 기록 및 재생, 단방향 데이터 흐름, 종속 변형)을 보존하고 Dispatcher 및 상점 등록을 도입하지 않고도 새로운 이점 (간편한 실행 취소, 핫 다시로드)을 추가합니다.

더 높은 수준의 추상화를 구현하는 동안 제정신을 유지하기 때문에 단순하게 유지하는 것이 중요합니다.

대부분의 Flux 라이브러리와 달리 Redux API 표면은 작습니다. 개발자 경고, 주석 및 온 전성 검사를 제거하면 99 줄이 됩니다. 디버깅 할 까다로운 비동기 코드가 없습니다.

실제로 읽고 모든 Redux를 이해할 수 있습니다.

Flux와 비교하여 Redux 사용의 단점에 대한 내 답변 도 참조하십시오.

출처 : https://stackoverflow.com/questions/32461229/why-use-redux-over-facebook-flux