티스토리 뷰
Redux를 사용하게 된 이유
리덕스를 사용하기 전, 리액트 프로젝트에서 상태를 관리하는 데에 컴포넌트끼리 직접 소통해야만 상태를 전달할 수 있었다.
투두리스트 컴포넌트 구조를 보면 다음과 같다.
- 투두 아이템을 작성 및 제출하는 Form
- 투두 아이템 상태 관리하는 App
- 투두 아이템 리스트를 보여주는 TodoList
사용자가 Form에서 투두를 작성하면 App에서 상태를 업데이트한 후 TodoList에게 투두 아이템 리스트를 전달한다.
이런 식으로 건너 건너 상태를 업데이트하고 전달하며 리렌더링 하는 방식으로 프로젝트 실행된다.
문제는 프로젝트의 규모가 커졌을 때 발생한다. 하나의 데이터 상태 관리하기 위해 여러 단계의 다리를 건너가게 된다면 코드의 양과 질이 낮아지게 된다.
Root에서 G까지 state(상태)를 전달하기 위해서 A, E를 거쳐야만 상태를 전달할 수 있다.
- A는 Root로부터 props를 전달받고 전달받은 props를 다시 E로,
- E는 A로부터 props를 전달받고 전달받은 props를 다시 G로...
이처럼 props를 오로지 하위 컴포넌트에게 전달하는 과정을 Props drilling이라고 부른다.
이러한 불필요한 과정을 생략해 주기 위해서 Redux를 사용하게 된다.
Redux를 사용하게 되면 상태값을 컴포넌트에 종속하지 않고 컴포넌트 외부에서 상태 관리할 수 있게 된다.
Redux와 Context API의 차이
리덕스를 사용하기 전 React에서 제공한 Context API를 사용하여 전역 상태 관리를 할 수 있었으며, 상태 관리 로직을 분리할 수 있었다. 이전의 Context API는 지금과는 다른 사용 방식으로 프로젝트에서 전역 상태 관리가 굉장히 까다로웠다. 그렇기 때문에 Context API보다 Redux를 전역 상태 관리 용도로 많이 사용되어 왔다.
1. 미들웨어
리덕스에는 미들웨어(Middleware)라는 개념이 존재한다. 리덕스로 상태 관리할 때에 useReducer를 사용했을 때의 개념인 리듀서 함수를 사용한다. 리덕스의 미들웨어를 사용하면 액션 객체가 리듀서에서 처리되기 전에 우리가 원하는 작업들을 수행할 수 있다. 미들웨어는 주로 비동기 작업을 처리할 때 많이 사용되며 성능 최적화 기능을 위한 여러 기능을 제공하기 때문에 복잡한 애플리케이션 상태 관리에 효과적으로 처리할 수 있다.
2. 유용한 함수와, Hooks
이전에 Context API와 useReducer를 사용할 때에는 Context 생성, Provider 설정, 그리고 커스텀 훅을 설정해야 하는 과정을 거쳤어야 했다. 리덕스는 이와 비슷한 작업들을 편리하게 해 줄 수 있는 여러 기능들이 존재한다.
connect 함수를 사용하면 리덕스의 상태 또는 액션 생성 함수를 컴포넌트의 props로 받아올 수 있으며, useSelector, useDispatch, useStore와 같은 Hooks를 사용하면 손 쉽게 상태를 조회하거나 액션을 디스패치할 수 있다.
connext 함수와 useSelector 함수에는 내부적으로 최적화가 잘 이루어져 있기 때문에 실제 상태가 바뀔 때만 컴포넌트가 리렌더링 된다.
반면 Context API는 이러한 최적화가 자동으로 이루어져 있지 않기 때문에 Context Provider 내부 컴포넌트 전부 리렌더링 된다.
3. 하나의 커다란 상태
Context API는 분산 집중화된 상태 관리 방식으로, 전역 상태를 관리할 때에 일반적으로 기능별로 Context를 만들어서 사용하는 것이 일반적이다. 반면 리덕스는 중앙 집중화된 상태 관리 라이브러리로, 상태를 하나의 스토어에 저장하고 액션과 리듀서를 통해 상태를 업데이트하는 방식으로 동작하기 때문에 매번 Context를 생성할 필요가 없다.
Redux와 Context API 활용 경우
리덕스는 복잡하고 대규모 애플리케이션에서의 상태 관리와 성능 최적화에 효과적이며, 컴포넌트 간의 통신이 필요한 경우에 적합하다. 반면에 Context API는 단순한 상태 관리에 간편하게 적용할 수 있으며, 프로젝트가 중규모 이하의 규모인 경우나 리액트 자체에서 제공하는 기능을 활용하고 싶은 경우에 유용하다.
출처