나는 이 답변을 읽고 보일러 플레이트를 줄였고, GitHub의 예를 몇 가지 보았고, 약간의 redux(to do 앱)도 시도했다.
제가 알기로는 공식적인 redex doc 동기는 기존의 MVC 아키텍처에 비해 장점을 제공합니다.하지만 이 질문에는 답이 없습니다.
Facebook Flux보다 Redux를 사용해야 하는 이유는 무엇입니까?
기능성 대 비기능성이라는 프로그래밍 스타일의 문제뿐입니까?아니면 redux 접근법에 따른 능력/개발 도구에 대한 질문입니까?스케일링?아니면 테스트?
redux는 기능적 언어에서 온 사람들을 위한 플럭스라고 말하는 것이 맞습니까?
이 질문에 답하려면 플럭스와 리덕스에 대한 구현 리덕스의 동기 부여 포인트의 복잡성을 비교할 수 있습니다.
다음은 공식 Redex 문서 동기 부여에 따른 동기 부여 포인트입니다.
- 낙관적인 업데이트 처리 (제가 알기론 5번째 포인트에는 거의 의존하지 않습니다.) facebook 플럭스로 구현하기 어렵습니까?)
- 서버에서의 렌더링(페이스북 플럭스도 가능합니다). redux와 비교하여 어떤 이점이 있습니까?
- 경로 전환을 수행하기 전에 데이터 가져오기(Facebook 플럭스에서는 왜 데이터를 가져올 수 없는가? 어떤 이점이 있습니까?
- 핫 새로고침(Respect Hot Reload를 사용하면 가능합니다. 왜 리덕스가 필요한가?
- 실행 취소/재설정 기능
- 다른 포인트는요?지속 상태처럼…
질문에 대한 답변
여기 레독스 작성자!
리덕스도 플럭스와 크게 다르지 않다.전반적으로 아키텍처는 동일하지만 Redux는 Flux가 콜백 등록을 사용하는 기능적 구성을 사용하여 복잡성을 줄일 수 있습니다.
Redux에는 근본적인 차이는 없지만, 플럭스에서는 구현이 어렵거나 불가능한 특정 추상화를 쉽게 또는 적어도 구현할 수 있습니다.
리듀서 구성
예를 들어 페이지 번호부여를 예로 들 수 있습니다.My Flux + React Router 예제에서는 페이지네이션이 처리되지만, 그 코드는 끔찍합니다.끔찍한 이유 중 하나는 Flux가 매장 전체에서 기능을 재사용하는 것을 부자연스럽게 만든다는 것입니다.2개의 스토어가 다른 액션에 대응해 페이지 매김을 처리할 필요가 있는 경우는, 공통의 베이스 스토어에서 상속하거나(bad! 상속을 사용할 때 특정의 설계에 자신을 잠그는 경우), 이벤트 핸들러내에서 외부적으로 정의된 함수를 호출하거나, Flux 스토어의 프라이빗 스테이트에서 어떻게든 동작할 필요가 있습니다.모든 것이 엉망진창이다.
한편, Redux의 페이지화는 환원제 구성 덕분에 자연스러운 것입니다.축소판입니다. 축소판 팩토리를 작성하여 페이지 번호 축소판을 생성하고 축소판 트리에 사용할 수 있습니다.이렇게 쉬운 이유는 Flux에서는 저장소가 평평하지만 Redux에서는 React 구성 요소를 중첩할 수 있는 것처럼 기능적 구성을 통해 환원기를 중첩할 수 있기 때문입니다.
이 패턴은 또한 no-user-code undo/redo와 같은 훌륭한 기능을 가능하게 합니다.플럭스 앱에 Undo/Redo를 두 줄의 코드로 연결하는 것을 상상할 수 있습니까? 거의 없어요. Redux를 사용하면 리듀서 구성 패턴 덕분에 가능합니다.새로운 것은 없습니다.이것은 Elm Architecture에서 개척되고 상세하게 기술된 패턴입니다.이 패턴은 플럭스의 영향을 받은 것입니다.
서버 렌더링
사람들은 Flux를 사용하여 서버 상에서 정상적으로 렌더링하고 있지만, 각각 20개의 Flux 라이브러리가 서버 렌더링을 “간단하게” 하려고 하는 것을 보면, 아마도 Flux는 서버에 대략적인 엣지를 가지고 있을 것입니다.사실 Facebook은 서버 렌더링을 많이 하지 않기 때문에 그들은 이것에 대해 크게 염려하지 않고 에코시스템에 의존하여 쉽게 만들고 있다.
전통적인 플럭스에서는 매장은 싱글톤입니다.즉, 서버상의 다양한 요구에 대한 데이터를 분리하는 것은 어렵습니다.불가능하진 않지만, 어렵죠.이것이 바로 대부분의 플럭스 라이브러리(새로운 플럭스 유틸리티도 포함)가 싱글톤 대신 클래스를 사용하는 것을 권장하는 이유입니다.그러면 요청별로 스토어를 인스턴스화할 수 있습니다.
Flux에서 해결해야 할 문제는 다음과 같습니다(자체 또는 Flummox 또는 Alt와 같은 즐겨찾는 Flux 라이브러리를 통해 해결).
- 스토어가 클래스인 경우 요청별로 디스패처를 사용하여 스토어를 만들고 폐기하려면 어떻게 해야 합니까?매장 등록은 언제 하나요?
- 스토어에서 데이터를 하이드레이팅하고 나중에 클라이언트에 다시 하이드레이팅하려면 어떻게 해야 하나요?이를 위해 특별한 방법을 구현해야 합니까?
분명히 (바닐라 플럭스가 아닌) 플럭스 프레임워크는 이러한 문제에 대한 해결책을 가지고 있지만, 저는 너무 복잡하다고 생각합니다.예를 들어 Flummox는 상점에서 구현하도록 요청합니다.Alt는 JSON 트리에서 자동으로 상태를 직렬화하는 기능을 제공함으로써 이 문제를 보다 효과적으로 해결합니다.
Redux는 한 단계 더 나아가 하나의 스토어(많은 리듀서에 의해 관리됨)만 존재하므로 (재) 하이드레이션을 관리하는 데 특별한 API가 필요하지 않습니다.스토어를 “플래시”하거나 “하이드레이팅”할 필요가 없습니다.스토어는 1개뿐이며, 스토어의 현재 상태를 읽거나 새로운 상태의 스토어를 작성할 수 있습니다.각 요청은 개별 스토어 인스턴스를 가져옵니다.Redux를 사용한 서버 렌더링에 대한 자세한 내용은 여기를 참조하십시오.
이것은 Flux와 Redux 모두에서 가능한 일이지만, Flux 라이브러리는 많은 API와 규약을 도입함으로써 이 문제를 해결하고, Redux는 개념적인 단순성 덕분에 애초에 그런 문제가 없기 때문에 해결할 필요도 없습니다.
개발자 경험
Redux가 인기 있는 Flux 라이브러리가 되려고 했던 것은 아닙니다.시간 여행으로 핫 새로고침에 관한 ReactEurope 강연을 할 때 쓴 것입니다.저는 한 가지 주요 목표를 가지고 있었습니다. 즉석에서 환원기 코드를 변경하거나 행동을 지우고 “과거 변경”을 가능하게 하여 상태가 다시 계산되는 것을 볼 수 있도록 하는 것입니다.
나는 이것을 할 수 있는 플럭스 라이브러리를 본 적이 없다.React Hot Loader는 또한 이러한 작업을 수행할 수 없습니다. 사실 Flux 저장소를 편집하면 Flux 저장소로 무엇을 해야 할지 모르기 때문에 고장이 납니다.
Redux가 리듀서 코드를 새로고침해야 할 경우 를 호출하고 앱은 새로운 코드로 실행됩니다.Flux에서는 데이터와 함수가 Flux 스토어에 얽혀 있기 때문에 “기능만 교체”할 수 없습니다.게다가 어떻게든 디스패처에 새로운 버전을 재등록해야 합니다.Redux에는 없는 것입니다.
생태계
Redux는 풍부하고 빠르게 성장하는 생태계를 가지고 있습니다.이는 미들웨어와 같은 몇 가지 확장 포인트를 제공하기 때문입니다.로깅, Promise, Observatables 지원, 라우팅, 불변성 개발 검사, 지속성 등의 사용 사례를 염두에 두고 설계되었습니다.이 모든 것이 유용한 것은 아니지만, 쉽게 조합할 수 있는 도구 세트를 사용할 수 있다는 것은 매우 좋은 일입니다.
심플함
Redux는 Flux의 모든 이점(액션 기록 및 재생, 단방향 데이터 흐름, 종속 돌연변이)을 보존하고 Dispatcher 및 스토어 등록 없이 새로운 이점(간단한 실행 취소, 핫 새로고침)을 추가합니다.
심플하게 하는 것이 중요합니다.심플하게 하는 것은, 보다 높은 레벨의 추상화를 실장하면서 제정신을 유지할 수 있기 때문입니다.
대부분의 플럭스 라이브러리와 달리 Redux API 표면은 매우 작습니다.개발자 경고, 주석 및 건전성 검사를 제거할 경우 99행입니다.디버깅할 까다로운 비동기 코드는 없습니다.
실제로 모든 Redux를 읽고 이해할 수 있습니다.
플럭스와 비교하여 Redux를 사용하는 단점에 대한 답변도 참조하십시오.
Quora에서 누군가 말한다:
우선 플럭스 없이 리액트로 앱 작성이 완전히 가능하다.
또, 이 그림에서는, 양쪽 모두를 간단하게 표시하기 위해서 작성했습니다.이 그림에서는, 모든 설명을 읽고 싶지 않은 유저에게는 간단한 회답입니다.
하지만 더 알고 싶다면 계속 읽어보세요.
순수한 반응부터 시작해서 Redux와 Flux를 배워야 한다고 생각합니다.React에 대한 실제 경험을 쌓은 후 Redx가 귀사에 도움이 되는지 여부를 확인할 수 있습니다.
Redx가 앱에 딱 맞는다고 느끼실 수도 있고, Redx가 실제로 경험하지 못한 문제를 해결하기 위해 노력하고 있다는 것을 알게 될 수도 있습니다.
Redx에서 직접 시작하면 과도하게 설계된 코드, 유지보수가 어려운 코드, 그리고 더 많은 버그가 발생할 수 있으며 Redx를 사용하지 않을 때보다 더 많은 코드가 발생할 수 있습니다.
Redux 문서에서:
동기
JavaScript 단일 페이지 애플리케이션의 요건이 점점 더 복잡해짐에 따라 당사의 코드는 이전보다 더 많은 상태를 관리해야 합니다.이 상태에는 서버 응답 및 캐시된 데이터뿐만 아니라 아직 서버에 유지되지 않은 로컬로 작성된 데이터가 포함될 수 있습니다.활성 경로, 선택한 탭, 스피너, 페이지 번호 제어 등을 관리해야 하기 때문에 UI 상태도 복잡해지고 있습니다.끊임없이 변화하는 이 상태를 관리하는 것은 어렵습니다.모델이 다른 모델을 업데이트할 수 있는 경우 뷰는 모델을 업데이트하여 다른 모델을 업데이트할 수 있으며, 이로 인해 다른 뷰가 업데이트될 수 있습니다.언제, 왜, 어떻게 앱 상태를 제어할 수 없게 되므로 앱에서 무슨 일이 일어나는지 더 이상 이해할 수 없습니다.시스템이 불투명하고 결정적이지 않으면 버그를 재현하거나 새로운 기능을 추가하는 것이 어렵습니다.
이 정도로는 충분치 않다는 듯이 프런트 엔드 제품 개발에서 새로운 요구사항이 보편화되고 있음을 고려하십시오.개발자로서 우리는 루트 전환을 수행하기 전에 최적의 업데이트, 서버 측 렌더링, 데이터 가져오기 등을 처리해야 합니다.지금까지 다루지 않았던 복잡함을 관리하려고 하고 있기 때문에, 다음과 같은 질문을 피할 수 없습니다.포기해야 할 때인가?대답은 ‘아니오’입니다.
이 복잡성은 인간의 마음이 이해하기 어려운두 가지 개념을 혼합하고 있기 때문에 다루기가 어렵습니다돌연변이 및 비동기성입니다멘토스와 콜라라고 부르죠.둘 다 떨어져 있으면 좋을 수 있지만, 함께 있으면 엉망진창이 됩니다.React와 같은 라이브러리는 비동기 DOM 조작과 직접 DOM 조작을 모두 제거함으로써 뷰 계층에서 이 문제를 해결하려고 합니다.그러나 데이터 상태 관리는 사용자에게 달려 있습니다.이것이 바로 Redux가 필요한 부분입니다.
Flux, CQRS 및 Event Sourcing의 뒤를 이어 Redux는 업데이트가 발생하는 방법과 시기에 일정한 제한을 가함으로써 상태 돌연변이를 예측 가능하게 하려고 합니다.이러한 제한은 Redux의 세 가지 원칙에 반영되어 있습니다.
핵심 개념
Redux 자체는 매우 간단합니다.앱 상태가 일반 개체로 설명된다고 가정해 보십시오.예를 들어, ToDo 앱의 상태는 다음과 같습니다.
{ todos: [{ text: 'Eat food', completed: true }, { text: 'Exercise', completed: false }], visibilityFilter: 'SHOW_COMPLETED' }이 개체는 설정자가 없다는 점을 제외하고 “모델”과 같습니다.이는 코드의 다른 부분이 임의로 상태를 변경할 수 없기 때문에 재현하기 어려운 버그가 발생합니다.
주의 내용을 변경하려면 액션을 디스패치해야 합니다.액션은 발생한 상황을 설명하는 단순한 JavaScript 오브젝트(마법을 도입하지 않는 방법에 주의해 주세요)입니다.다음은 몇 가지 액션의 예를 제시하겠습니다.
{ type: 'ADD_TODO', text: 'Go to swimming pool' } { type: 'TOGGLE_TODO', index: 1 } { type: 'SET_VISIBILITY_FILTER', filter: 'SHOW_ALL' }모든 변경 사항을 액션으로 설명하도록 강제함으로써 앱에서 무슨 일이 일어나고 있는지 명확하게 파악할 수 있습니다.만약 뭔가가 변했다면, 우리는 왜 변했는지 알고 있다.행동은 일어난 일에 대한 빵조각과 같다.마지막으로 상태와 동작을 연결하기 위해 환원기라는 함수를 작성합니다.다시 말하지만 마법은 없습니다. 상태와 액션을 인수로 삼고 앱의 다음 상태를 반환하는 함수입니다.큰 앱에서는 이러한 함수를 작성하기 어렵기 때문에, 상태의 일부를 관리하는 작은 함수를 작성합니다.
function visibilityFilter(state = 'SHOW_ALL', action) { if (action.type === 'SET_VISIBILITY_FILTER') { return action.filter; } else { return state; } } function todos(state = [], action) { switch (action.type) { case 'ADD_TODO': return state.concat([{ text: action.text, completed: false }]); case 'TOGGLE_TODO': return state.map((todo, index) => action.index === index ? { text: todo.text, completed: !todo.completed } : todo ) default: return state; } }또한 두 개의 리듀서를 해당 상태 키에 대해 호출하여 앱의 전체 상태를 관리하는 또 다른 리듀서를 작성합니다.
function todoApp(state = {}, action) { return { todos: todos(state.todos, action), visibilityFilter: visibilityFilter(state.visibilityFilter, action) }; }이것이 기본적으로 Redux의 전체 아이디어입니다.Redux API는 사용하지 않았습니다.이 패턴을 용이하게 하기 위해 몇 가지 유틸리티가 포함되어 있지만, 주요 아이디어는 작업 객체에 대한 응답으로 시간이 지남에 따라 상태가 어떻게 업데이트되는지 설명하는 것입니다.작성하는 코드의 90%는 단순한 JavaScript이며 Redx 자체, API 또는 마법은 사용하지 않습니다.
우선 Dan Abramov가 쓴 이 투고부터 읽어보는 것이 좋습니다.이 투고에서는, Flux의 다양한 실장과 redex를 집필하고 있던 당시의 Flux의 트레이드 오프에 대해 설명합니다.플럭스 프레임워크의 진화
둘째, 링크된 동기 페이지는 Redux의 동기뿐만 아니라 플럭스(및 리액트)의 동기에 대해서도 별로 언급하지 않습니다.이 3원칙은 보다 Redux에 특화되어 있지만 표준 Flux 아키텍처와의 구현 차이는 다루지 않습니다.
기본적으로 Flux에는 컴포넌트와의 UI/API 상호작용에 따라 상태 변화를 계산하고 컴포넌트가 서브스크라이브할 수 있는 이벤트로 브로드캐스트하는 여러 저장소가 있습니다.Redux에서는 모든 컴포넌트가 가입하는 스토어는 1개뿐입니다.IMO는 최소한 Redux가 데이터 흐름을 구성요소로 통합(또는 Redux가 말하는 것처럼 감소)하여 데이터 흐름을 더욱 단순화하고 통합한 반면, Flux는 데이터 흐름의 다른 측면을 모델로 통합하는 데 주력하고 있습니다.
저는 얼리어답터로 페이스북 플럭스 라이브러리를 사용하여 중간 크기의 단일 페이지 애플리케이션을 구현했습니다.
대화에 조금 늦었기 때문에, Facebook이 Flux의 실장을 컨셉의 증명이라고 생각하고 있는 것 같아서, 지금까지 주목받을 만한 것은 전혀 없는 것 같습니다.
Flux 아키텍처의 내부 작업을 더 많이 볼 수 있기 때문에 이 기능을 사용해 보시기 바랍니다.이것은 매우 교육적이지만, 동시에 Redux와 같은 라이브러리가 제공하는 많은 이점(작은 프로젝트에서는 그다지 중요하지 않지만, 큰 프로젝트에서는 매우 가치가 있습니다)을 제공합니다.
우리는 앞으로 Redux로 이동하기로 결정했고, 당신도 그렇게 할 것을 제안합니다.
다음은 Redx over Flux에 대한 간단한 설명입니다.Redux에는 디스패처가 없습니다.그것은 환원기라고 불리는 순수한 기능에 의존한다.디스패처는 필요 없습니다.각 작업은 한 개 이상의 축소자가 처리하여 단일 저장소를 업데이트합니다.데이터는 불변하므로 감소기는 스토어를
업데이트하는 새 업데이트된 상태를 반환합니다.