Redux란?
리덕스는 가장 많이 사용하는 리액트 상태 관리 라이브러리이다. 리덕스를 사용하면 컴포넌트의 상태 업데이트 관련 로직을 다른 파일로 분리시켜서 더욱 효율적으로 관리할 수 있다.
또한, 컴포넌트끼리 똑같은 상태를 공유해야 할 때도 여러 컴포넌트를 거치지 않고 손쉽게 상태 값을 전달하거나 업데이트할 수 있다.
리덕스 라이브러리는 전역 상태를 관리할 때 굉장히 효과적이다. 물론 리덕스를 사용하는 것이 유일한 해결책은 아니다.
단순히 전역 상태 관리만 한다면 Context API를 사용하는 것만으로도 충분하다. 하지만 리덕스를 사용하면 상태를 더욱 체계적으로 관리할 수 있기 때문에 프로젝트의 규모가 클 경우에는 리덕스를 사용하는 편이 좋다. 코드의 유지 보수성도 높여주고 작업 효율도 극대화해주기 때문이다. 추가로 아주 편리한 개발자도구도 지원하며, 미들웨어라는 기능을 제공하며 비동기 작업을 훨씬 효율적으로 관리할 수 있게 해주기도 한다
상태란?
상태(state) 란 간단하게 말하면 데이터다. 덧붙이자면 상태는 컴포넌트 내부에서 사용하는 데이터라고 할 수 있다.
Redux의 기본 개념
Store (스토어)
- 컴포넌트와 별개로 스토어라는 공간이 있어 그 스토어 안에 앱에서 필요한 상태를 담는다.
- 컴포넌트에서 상태 정보가 필요할 때 스토어에 접근한다.
Action (액션)
- 앱에서 스토어에 운발할 데이터를 말한다. (주문서)
- 자바스크립트 객체 형식으로 되어있다.
Reducer (리듀서)
- Aciton을 통해 그 결과 어플리케이션의 상태가 어떻게 바뀌는지 특정하는 즉, state에 변화를 일으키는 함수이다.
Dispatch (디스패치)
- store의 내장 함수 중 하나로, action을 발생시킨다.
- action을 파라미터로 전달하고 reducer를 호출한다.
Subscribe (구독)
- sotre의 내장 함수 중 하나로, 특정 함수를 전달해주면 action이 dispatch 되었을 때마다 전달된 함수가 호출된다.
Redux의 3가지 규칙
하나의 애플리케이션안에는 하나의 store가 있다.
- store는 단 하나만을 생성해서 상태를 관리할 수 있다. 그 대신 reducer를 여러개 만들어서 다양한 상태를 구분해 관리할 수 있다
상태는 읽기전용이다.
- 리액트에서 상태에 불변성을 유지시켜주는 것과 비슷하다. 기존의 상태는 건드리지 않고 새로운 상태를 생성해 상태를 변경시켜준다. 마치 setState 처럼 말이다. 리덕스에서 불변성을 유지해야 하는 이유는 내부적으로 상태가 변경되었는지 검사를 확인하기 위해 shalloew equality 검사를 하기 때문이다
변화를 일으키는 함수, Reducer는 순수함수여야 한다.
-
reducer 함수는 상태와 액션 객체를 인자로 받게 되는데 이때 이전의 상태를 변경하는 것이 아닌 새로운 상태 객체를 만들어서 반환해야 한다. 그리고 같은 인자로 호출된 reducer는 언제나 같은 값을 반환하는 순수 함수로 만들어져야 한다.
-
동일한 인풋이라면 동일한 아웃풋이 있어야 한다. 그러나 일부 로직들 중 실행 할 때마다 다른 결과값이 나타날 수 있다. new Date()나 Math.random(), 과 같은 네트워크 요청 등이 있는데 이러한 작업들은 결코 순수하지 않은 작업이므로, Reducer 함수의 바깥에서 처리해줘야 한다. 이런 것을 하기 위해 Redux Middleware를 사용하곤 한다.
Redux가 큰 프로젝트에서 쓰기 좋은 이유?
Redux는 props 없이 state(상태)를 공유할 수 있게 도와주는 라이브러리이다. Redux가 설치되어 있다면 js 파일 하나에 state들을 보관할 수 있고 그걸 모든 컴포넌트에서 사용할 수 있다
이 때문에 엄청 멀리있는 컴포넌트에도 귀찮은 props 전송을 할 필요가 없어지기 때문에 프로젝트가 클수록 컴포넌트가 많아지니 그럴 때 사용하면 좋다
Redux의 장점
상태 예측
- 동일한 상태와 액션이 리듀서에 전달되면 리듀서는 순수 함수이기 때문에 항상 동일한 결과가 생성된다. 또한 이전 상태 사이를 앞뒤로 이동하고 결과를 실시간으로 볼 수 있다.
유지 보수 용이
- 코드를 구성하는 방법에 대해 엄격하므로 Redux에 대한 지식이 있는 사람이 Redux 애플리케이션의 구조를 더 쉽게 이해할 수 있다.
디버깅
- 리덕스는 단방향으로 데이터가 흐른다. 즉, 버그를 예측하기쉽다. 내가 어떤 액션을 실행하였고 어떻게 데이터가 흐르는지 예측이 가능하여 디버깅에 매우 용이하다.
한 곳에서 관리
- store를 이용하여 상태를 한 곳에서 관리하기 때문에 전역상태를 관리할 때 효율적이다.
Redux의 단점
코드의 증량
- 리덕스로 코드를 구현하는 순간 필수적으로 만들어야하는 파일이 있기 때문에 코드량이 그만큼 증가하게 된다.
읽기 전용
- 리덕스는 상태를 읽기 전용으로 취급하지만 읽기 전용으로 만들어주지는 않는다. 때문에 항상 직접 수정하지 않게 하기위해 주의해야 한다.
보일러플레이트 코드
- Redux를 사용하면 액션 타입, 액션 생성자, 리듀서 등 많은 보일러플레이트 코드를 작성해야 한다. 상태의 변화를 추적하기 위해 반복적인 작업을 수행해야 하므로 코드 양이 증가할 수 있다. 이는 프로젝트의 초기 설정과 유지 관리에 비용이 들 수 있다.
과도한 관리
- Redux는 작은 규모의 애플리케이션에 비해 상태 관리를 위해 추가적인 설정과 구성이 필요하다. 상태 관리를 위해 Redux를 도입하는 것이 필요한지 신중하게 평가해야 한다. 작은 규모의 프로젝트에서는 Redux보다 간단한 상태 관리 라이브러리를 고려할 수 있다
