리덕스의 구성요소
- Store : 리덕스의 데이터들을 저장하기 위한 저장소
- State : 리덕스 Store에 저장되어 있는 데이터
- Action : Store에 저장된 데이터(State)에 변화를 주기 위한 행동
- Action Creator : Action을 생성하는 생성자 역할
- Reducer : Action이 발생하면 Action을 실제로 처리하는 역할을 하는 함수 (리덕스 State에 변화를 주는 역할)
Immutability (불변성)
리덕스의 3가지 원칙 중에서 두 번째 원칙은 State is read-only 였고, 세 번째 원칙은 Changes are made with pure functions 였다. 여기에 불변성이 적용된다.
리덕스 State는 읽기 전용이며, State를 변경하기 위해서는 새로운 State를 생성해야 한다.
그리고 새로운 State를 생성하는 과정은 Reducer라고 불리는 Pure function을 통해 이뤄진다.
즉, 입력으로 받은 이전 상태를 직접 변경하는 것이 아니라 새로운 상태 객체를 만들어서 리턴한다는 것이며,
또한 같은 입력에 대해서는 항상 같은 결과를 리턴한다는 뜻이다.
리덕스 State 생성 후에는 값을 바꿀 수 없다. 값을 바꾸기 위해서는 기존 State를 변경하는 것이 아닌,
새로운 State를 생성해야 한다.
이러한 불변성을 적용하기 위해서 immer 라는 라이브러리를 사용한다.
Immer.js는 state에 불변성을 적용하기 편리하게 도와주는 도구라고 생각하면 된다.
Redux Toolkit은 불변성을 지키기 위해, 내부적으로 immer를 사용하고 있다.
어떤 경우에 리덕스를 사용해야 할까?
- 하나의 상태를 여러 컴포넌트에서 접근해야 하는 경우
대표적인 예로 사용자의 로그인 여부를 들 수 있다.
여러 컴포넌트에서 사용자의 로그인 여부에 따라 다른 UI를 보여주고자 할 때,
로그인 여부(state)를 리덕스를 통해서 쉽게 관리할 수 있다.
- 한 곳에서 상태들을 관리하고 싶은 경우
여러 가지 state들을 종류별로 잘 분류해서 한 곳에서 관리하고 싶을 때, 리덕스를 통해 관리하는 것이 좋다.
Redux vs Context API
Context API
Context는 리액트 컴포넌트들 사이에서 데이터를 기존의 props를 통해 전달하는 방식 대신, component tree를 통해 곧바로 컴포넌트로 전달하는 새로운 방식을 제공한다.
이 그림은 props를 통해 상위 컴포넌트에서 하위 컴포넌트로 데이터를 전달하는 일반적인 방식을 보여준다.
이 방식의 단점은 여러 컴포넌트에 걸쳐 자주 사용되는 데이터(예: 로그인 여부, 프로필 정보 등)를 전달하려면 반복적인 코드가 많아지고 복잡해진다는 것이다.
예를 들어,
위 그림에서 루트 노드에 있는 데이터를 C 컴포넌트로 전달하려면 최소 2번을 props로 전달해야 한다.
이러한 불편한 점을 개선하기 위해 생겨난 것이 바로 Context이다.
Context를 사용하면 일일이 props로 전달할 필요 없이, 데이터를 필요로 하는 컴포넌트에 곧바로 데이터를 전달할 수 있다.
따라서 코드도 깔끔해지고 데이터를 한 곳에서 관리하기 때문에 디버깅을 하기에도 유리하다.
여기까지만 보면 Context가 하는 역할과 용도는 Redux와 매우 유사하다.
실제로 두 가지 기술 모두 여러 단계에 걸쳐서 props를 통해 데이터를 전달하는 prop drilling이라고 불리는 문제를 해결하기 위한 방법이다.
Redux나 Contex API를 사용하면, 이렇게 데이터를 특정 계층에 있는 컴포넌트에 직접 전달할 수 있게 된다.
그리고 내부적으로 Redux는 리액트 Context API를 사용하여, 컴포넌트 Tree를 따라 Store에 있는 데이터들을 전달한다.
Context API와 리덕스의 차이점
-
Redux를 사용하면 앞에서 redux-devtools라는 강력한 도구를 사용할 수 있다.
redux-devtools는 모든 상태의 변화를 시각적으로 확인할 수 있게 해주며, 이전 상태로 돌아가서 하나씩 Action을 실행하면서 디버깅할 수도 있다.
애플리케이션의 규모가 커질수록 꼭 필요한 기능이다. -
Context API는 특정 Context에 의존하는 컴포넌트들을 분리시킬 수 있다.
여러 개의 Context를 만들고 해당 Context와 관련 있는 컴포넌트들만을 묶어서 분리시킬 수 있다.
이렇게 분리시키면 해당 Context와 관련없는 컴포넌트는 데이터에 접근이 불가능해지기 때문에, side effect를 사전에 방지할 수 있다.
- Redux와 Context API는 데이터를 처리하는 방식이 다르다.
Redux는 전체 애플리케이션의 데이터를 리덕스 Store라고 불리는 하나의 거대한 객체로 관리한다.
그리고 사전에 정의된 Action과 Reducer를 통해서만 상태를 변경할 수 있다.
반면에 Context는 오로지 하나로 구성되어 있지도 않고, 데이터를 별도로 관리하지도 않는다.
Context는 state를 들고 있는 것이 아니라 state를 전달하기 위한 통로의 역할만 하는 것이다.
만약 Context API를 사용해서 state를 업데이트하려면, 상위 컴포넌트의 state에 의존할 수밖에 없다.
상위 컴포넌트에서 state를 업데이트하고, 변경된 값을 Context라는 통로를 통해 하위 컴포넌트로 전달하는 것이다.
Redux와 Context API 중에서 어떤 것을 사용해야 할까?
각자 개발하려는 애플리케이션에 따라서 적합한 기술을 선택해서 사용하는 것이 중요하다.
규모가 크고 관리해야 할 상태가 많다면 Redux를 사용하는 것이 좋고,
규모가 작고 관리해야 할 상태가 몇 개 없다면 Context API를 사용하는 것이 더 나은 선택일 수 있다.
