상태 관리가 필요한 경우
- 하나가 아닌 여러 구성 요소에 영향을 미치는 조건 → 교차 구성 요소
- 단일 모달을 표시하거나 숨기기 위해 여러 구성 요소가 함께 작동할 때 소품 드릴
- 상태가 애플리케이션의 모든 구성 요소에 영향을 미치는 경우 → 앱 전체 상태, 예: 나. 사용자 인증
이 경우 국가 행정이 필요하다는 것을 인정하기 쉽습니다.
그런데 왜 React의 내장 컨텍스트 API 대신 Redux가 필요한가요?그건 또 다른 질문입니다.
응답 컨텍스트에는 몇 가지 잠재적인 단점이 있습니다.
이것은 가능한 한 큰 단점이 아니므로 일반적으로 앱 전체 상태에 대해 컨텍스트 또는 redux를 사용합니다.
그러나 전체 앱 전체 상태는 Redux를 사용하며 앱에 중요한 일부 다중 구성 요소 상태에 대한 컨텍스트를 계속 사용할 수 있습니다.
컨텍스트의 단점
- 구성 및 상태 관리는 매우 복잡할 수 있습니다.
프로젝트가 클수록 문제가 될 가능성이 높아집니다.
앱의 크기가 커짐에 따라 contextProvider 구성 요소가 많아져 매우 많이 중첩된 JSX 코드가 생성됩니다.
물론 모든 것을 포함하는 하나의 큰 contextProvider로 관리할 수 있지만 하나의 구성 요소에서 여러 상태를 관리하는 코드를 작성하면 유지 관리가 어렵습니다. - React에서 공식적으로 언급되는 단점이 있습니다.
컨텍스트는 테마 변경이나 인증과 같은 간헐적인 업데이트에는 적합하지만 빈번한 데이터 변경에는 적합하지 않다고 언급되었습니다.
그러나 React Context는 모든 시나리오와 경우에 Redux를 대체하기에 적합하지 않습니다.
이것이 Redux가 작동하는 방식입니다
중앙 리포지토리와 구성 요소가 있고 리포지토리의 데이터가 변경되는 경우 변경 사항을 인식하고 그에 따라 대응하며 사용자 인터페이스를 업데이트해야 합니다.
이렇게 하려면 중앙 리포지토리에 대한 구독을 설정합니다.
구성 요소는 저장소를 구독하고 저장소는 데이터가 변경될 때 구성 요소에 알립니다.
그런 다음 구성 요소는 필요한 데이터를 가져옵니다.
데이터는 반대 방향으로 흐르지 않습니다.
대신 리듀서라는 개념을 사용합니다.
플래트너를 설정하면 플래트너가 변환을 처리합니다.
입력을 받고 변환하고 축소하는 함수입니다.
이것은 후크의 useReducer와 다릅니다.
이제 구성 요소와 접기 기능을 어떻게 연결합니까?
행동의 개념이 작용하는 곳입니다.
구성 요소가 작업을 트리거하면 구성 요소가 작업을 트리거한다고 말할 수 있습니다.
리듀서가 해야 할 일을 설명합니다.
Redux는 이 작업을 감속기에 전달하고 수행하려는 작업에 대한 설명을 읽습니다.
액션을 리듀서에 전달하고 리듀서는 액션이 원하는 것을 수행합니다.
그런 다음 감속기는 중앙 데이터 저장소의 이전 상태를 실제로 대체하는 새 상태를 내보냅니다.
이 경우 구독 구성 요소에 알림이 전송되고 사용자 인터페이스를 업데이트할 수 있습니다.