React Context API가 Store의 대안이 되는지 여부

작문 동기

최근 1년간 구조를 결정할 때 두 현장에서 제목에 대한 질문을 받았는데 많은 분이 신경 쓰신다고 생각해서 정리해보고 싶었어요.

결론

결론부터 쓰면 대체할 수 없다.
양자의 특성을 바탕으로 양자가 공존하는 토대에서 구분하여 사용하거나 응용 프로그램의 규모에 따라 그 중 하나를 선택할 수 있다.

Context API의 피쳐

원래 이 토론(특히 Redux)이 발생한 계기는 React 16.3에서 Context API가 대폭 변경돼 공개된 것이다.
왜 새로운 Context API가 Redux의 대안으로 여겨질까요? 우리는 대체적으로 Context API를 관찰할 것입니다.

개요

React 구성 요소의 특정 트리에 대해 글로벌 데이터를 제공하며 자손 구성 요소는 차원과 무관한 글로벌 데이터에 접근할 수 있습니다.
※ React의 4공식 문서추가 참조

관심

Context API의 관심사는 prop driling을 제거하는 것입니다.
레드ux의 관심도 비슷해서 그런 것 같아요, 대체가 됐잖아요.

개발상의 차이

Redux와 Context API의 차이점은 무엇입니까?
물론 이것뿐만이 아니라, 나는 책상 위에 모아 보았다.
Redux
Context API
역할 영역
전체 애플리케이션
후손
관리 대상
전체 애플리케이션 상태
빈도가 낮은 데이터 변경
중간부품
있다
없음
개발자 도구
있다
없음
Context API는 전체 어플리케이션을 관리하는 상태가 아니라 React Component의 트리 구조에서 글로벌 데이터를 공유하도록 설계되었습니다.
Context is designed to share data that can be considered “global” for a tree of React components, such as the current authenticated user, theme, or preferred language.
또한 인증 정보와 주제 등이 객체로 예시된 것처럼 (변경 빈도가 많음) 상태는 Context API로 처리되지 않았다.
4공식 문서에서 언급한 바와 같이 Context API는 불필요한 재그림을 일으키기 쉬우며 상태를 처리할 때 그 통제는 개발 원가를 증가시킨다.

제각기 적합한 상황

상술한 차이를 바탕으로 각자의 적합한 사례를 총결하였다.
Redux
Context API
이유를 판단하다
어플리케이션 크기
큰
작은
역할 영역의 차이
데이터 업데이트 빈도
수두룩하다
소량
디자인 사상을 통제하고 재구성하다
비동기 처리
수두룩하다
소량
중간부품 유무
양자의 디자인 사상과 목적이 워낙 다르기 때문에 상황에 따라 구분해서 사용해야 한다.
따라서 스토어를 Context API로 대체할 수 없습니다.