React Context vs React Redux는 언제 사용해야합니까? [닫은]

React 16.3.0이 릴리스 되었으며 Context API는 더 이상 실험 기능이 아닙니다. Dan Abramov (Redux 제작자)는 여기 에 대해 좋은 의견을 썼습니다. 그러나 Context가 여전히 실험적인 기능이었던 것은 2 년이었습니다.

내 질문은, 당신의 의견 / 경험 에서 React Redux 보다 React Context 를 언제 사용해야 합니까?

로 상황은 더 이상 실험적인 기능입니다 그리고 당신은 직접 응용 프로그램에서 컨텍스트를 사용할 수 있으며,이를 위해 설계되었습니다 무엇을 중첩 구성 요소에 데이터를 전달하는 위대한 사람이 될 것입니다.

Mark erikson은 자신의 블로그에서 다음 과 같이 썼습니다 .

소품을 전달하지 않기 위해 Redux 만 사용하는 경우 컨텍스트는 Redux를 대체 할 수 있지만 처음에는 Redux가 필요하지 않았을 것입니다.

컨텍스트는 또한 Redux DevTools상태 업데이트를 추적하는 기능, middleware중앙 집중식 응용 프로그램 논리를 추가하는 기능 및 기타 강력한 기능을 제공하지 않습니다 Redux .

Redux@danAbramov가 언급했듯이 훨씬 강력하고 제공 Context Api하지 않는 많은 기능을 제공합니다.

React Redux는 내부적으로 컨텍스트를 사용하지만 공개 API에서이 사실을 공개하지 않습니다. 따라서 React Redux를 통해 컨텍스트를 사용하는 것이 직접 변경되는 것보다 훨씬 안전하다고 생각해야합니다.

최신 컨텍스트 API를 준수하도록 구현을 실제로 업데이트하는 것은 최대 Redux

최신 Context API는 Redux를 사용하여 구성 요소간에 데이터를 전달하는 응용 프로그램에 사용할 수 있지만 중앙 집중식 데이터를 사용하고 Action 제작자에서 API 요청을 처리하는 응용 프로그램 은 redux를 사용 redux-thunk하거나 redux-saga여전히 필요합니다. 이 redux 외에도 redux-persistlocalStorage에 저장소 데이터를 저장하고 새로 고칠 때 다시 수화 할 수있는 것과 같은 다른 라이브러리가 있습니다.이 컨텍스트 API는 여전히 지원하지 않습니다.

@dan_abramov는 자신의 블로그에서 언급 한 바와 같이 당신은 돌아 오는 필요하지 않을 수도 , 그 REDUX 같은 유용한 응용 프로그램을 가지고

• 상태를 로컬 스토리지로 유지 한 다음 즉시 스토리지에서 부팅합니다.
• 서버의 사전 채우기 상태를 HTML로 클라이언트에 보낸 다음 즉시 부팅합니다.
• 사용자 조치를 직렬화하고 상태 스냅 샷과 함께 자동화 된 버그 보고서에 첨부하여 제품 개발자
  가 오류를 재현하기 위해이를 재생할 수 있습니다.
• 네트워크를 통해 액션 객체를 전달하여 코드 작성 방식을 크게 변경하지 않고도 협업 환경을 구현할 수 있습니다.
• 코드 작성 방법을 크게 변경하지 않고 실행 취소 기록을 유지하거나 낙관적 돌연변이를 구현합니다.
• 개발중인 상태 기록 사이를 이동하고 코드가 변경 될 때 조치 기록에서 현재 상태를 다시 평가하십시오 (La TDD).
• 제품 개발자가
  앱에 대한 사용자 정의 도구를 작성할 수 있도록 개발 도구에 완전한 검사 및 제어 기능을 제공하십시오 .
• 대부분의 비즈니스 로직을 재사용하면서 대체 UI를 제공하십시오.

이 많은 응용 프로그램으로 Redux가 새로운 컨텍스트 API로 대체 될 것이라고 말하기에는 너무 이릅니다

소품을 깊이 중첩 된 컴포넌트로 전달하지 않도록 Redux 만 사용하는 경우 Redux를 ContextAPI로 바꿀 수 있습니다. 이 사용 사례를위한 것입니다.

반면, 다른 모든 것에 Redux를 사용하는 경우 (예측 가능한 상태 컨테이너가 있고, 구성 요소 외부에서 응용 프로그램의 논리를 처리하고, 응용 프로그램의 상태를 중앙 집중화하며, Redux DevTools 를 사용하여 응용 프로그램의 상태, 시기, 장소, 이유 및 방법을 추적하는 경우 Redux Form , Redux Saga , Redux Undo , Redux Persist , Redux Logger 등과 같은 플러그인을 사용 하면 Redux를 포기할 이유가 없습니다. ContextAPI는이 중 하나를 제공하지 않습니다.

그리고 개인적으로 Redux DevTools 확장 프로그램 은 놀랍고 과소 평가 된 디버깅 도구이며 Redux를 계속 사용하는 것으로 정당화됩니다.

일부 참고 문헌 :

• Redux는 아직 죽지 않았습니다!
• Redux가 필요하지 않을 수 있습니다
• 반응 고리가 Redux를 대체합니까?

API 호출을 만들고 (Axios를 사용하여) 리듀서에 응답을 디스패치하기 위해 redux-thunk와 함께 redux를 사용하는 것을 선호합니다. 깨끗하고 이해하기 쉽습니다.

컨텍스트 API는 React 구성 요소가 상점에 연결되는 방법에 대한 react-redux 부분에 따라 매우 다릅니다. 이를 위해 react-redux가 좋습니다. 그러나 원하는 경우 컨텍스트가 공식적으로 지원되므로 react-redux 대신 컨텍스트 API를 사용할 수 있습니다.

따라서 질문은 컨텍스트 API 대 반응-redux가 아니라 컨텍스트 API 대 반응-redux이어야합니다. 또한 질문은 약간 의견이 있습니다. 나는 react-redux에 익숙하고 모든 프로젝트에서 사용하기 때문에 계속 사용할 것입니다. (변경할 동기가 없습니다).

그러나 지금 바로 redux를 배우고 있고 어디에서나 사용하지 않았다면 Context API에 샷을 제공하고 react-redux를 사용자 정의 Context API 코드로 대체하는 것이 좋습니다. 어쩌면 그런 식으로 훨씬 깨끗할 수도 있습니다.

개인적으로, 그것은 친숙성의 문제입니다. 그것들이 동등하기 때문에 하나를 선택해야 할 명확한 이유는 없습니다. 그리고 내부적으로 react-redux는 Context를 사용합니다.

Redux를 사용해야하는 유일한 이유는 다음과 같습니다.

• 전역 상태 객체를 원합니다 (디버깅 가능성, 지속성 등과 같은 다양한 이유로 ...)
• 앱은 크거나 크며 많은 개발자에게 확장되어야합니다. 이러한 경우 아마도 일정 수준의 간접 지식 (예 : 이벤트 시스템)이 필요할 수 있습니다. 조직은 실제로들을 수 있습니다

전체 앱에 대해 간접적 인 수준이 필요하지 않을 수도 있으므로 스타일을 혼합하고 로컬 상태 / 컨텍스트와 Redux를 동시에 사용하는 것이 좋습니다.

• 다양한 목적으로 미들웨어를 사용해야하는 경우. 예를 들어, 로깅 조치, 오류보고, 서버의 응답에 따라 다른 요청 디스패치 등
• 여러 끝점에서 오는 데이터가 단일 구성 요소 /보기에 영향을주는 경우
• 응용 프로그램의 작업을보다 효과적으로 제어하려는 경우 Redux는 추적 작업 및 데이터 변경을 가능하게하여 디버깅을 크게 단순화합니다.
• 서버 응답으로 응용 프로그램의 상태를 직접 변경하지 않으려면 Redux는이 데이터를 적용 할 방법,시기 및 여부를 결정할 수있는 계층을 추가합니다. 관찰자 패턴. 전체 앱에서 여러 게시자와 구독자를 만드는 대신 구성 요소를 Redux 저장소에 연결하기 만하면됩니다.

From : 언제 Redux를 사용합니까?