상태 관리 라이브러리 Redux를 사용할 이유

ReactJS는 보통 useState Hook을 통해서 state를 만들고 setState 함수를 통해 해당 state를 관리한다.

state는 해당 컴포넌트에 종속되며, 하위 컴포넌트에서 해당 state를 사용하고자 하는 경우에는 state와, 이 state를 조작하는 setState 함수를 props를 통해서 지속적으로 전달해주어야 한다.

바로 아래의 컴포넌트면 괜찮을 수도 있으나, 하위의 하위의 하위 컴포넌트로 이어지게 되는 경우에는 지속적으로 props를 전달해야 한다던가, 최상위 컴포넌트가 모든 state를 지니고 있어야한다던가, 종국에는 코드의 직관성이 떨어지고 복잡해져 오타 등의 코드 실수가 생기기 쉬워진다.

하지만 상태 관리 라이브러리인 redux를 사용한다면 — 비단 모던 프론트엔드 프레임워크인 ReactJS가 아닌 바닐라 자바스크립트의 개발 환경이라도 — 컴포넌트 외부에서 상태를 관리하므로 보다 쉽게 유지보수를 할 수 있고, 보다 직관적으로, 객체지향적으로 코드를 짤 수 있다.

redux는 상태를 저장하는 store가 있고, 상태를 어떻게 변경시킬건지에 대한 정보를 담은 action 객체를, action 객체를 전달하는 dispatch를 통해, 상태를 변경할 때 사용하는 reducer 함수에 전달함으로써 변경한 상태를 새로 반환한다.

물론, 그렇다면 모두가 redux를 사용했을테지만, 장점만 있는 것은 아니다.

redux는 상태가 플레인한 객체 혹은 배열이길 요구한다.

또한, 상태의 변화를 조작하는 구조를 사이드 이펙트가 없는 순수 함수이길 요구하며, 시스템의 변경을 플레인한 객체로 하기를 요구한다.

간단한 프로젝트 같은 경우에는 useState Hook을 이용해 상태를 관리하는 것이 더욱 쉽고 편할 수도 있다.

Three Principles | Redux

그렇다면 어떤 경우에 개발을 위한 개발 도구로서 redux가 도움을 줄 수 있을까?

• local storage에 상태를 유지시키고, 시작하면서 불러올 때.
• 상태를 서버에서 미리 채워, HTML에 담고 클라이언트로 보내어 앱을 시작하면서 다시 불러올 때.
• 사용자의 액션을 직렬화하고 그것을 상태의 정보와 함께 자동으로 버그 리포트에 첨부하려 할 때 — 이로 인해 개발자들은 해당 에러들을 재현해볼 수 있다.
• 드라마틱한 코드 변경 없이 협업 환경을 구현하려 할 때 — 상태 객체를 네트워크를 통해서 보낸다면 드라마틱한 코드 변경 없이 협업 환경을 구현할 수 있다.
• 실행 취소 기록의 관리, 혹은 낙관적인 변경을 드라마틱한 코드 변경 없이 구현하려 할 때.
• 개발할 때, 상태의 히스토리들을 오가며, 코드가 변경될 때의 액션의 히스토리로부터 현재 상태를 다시 평가하는 작업을 TDD(Test Driven Development, 테스트 주도 개발)방식으로 진행할 수 있다.
• 완전한 검사와 제어 능력을 개발 도구에게 제공하여 개발자들은 그들의 애플리케이션을 위해 커스텀 도구를 빌드할 수 있게 해 준다.
• 비즈니스 로직의 대부분을 재사용하여 UI를 변경할 수 있게끔 해 준다.

물론, redux가 모든 상황에 꼭 필요한 것은 아니지만, 상기한 조건이나 상황에 처해있다면, 이런 redux, mobx, recoil 등의 다양한 상태 관리 라이브러리들은 개발자를 위한 개발 도구로서 꽤나 좋은 솔루션이 될 것이라고 생각한다.

이 글은 Dan Abramov의 ‘당신은 redux가 필요하지 않을수도 있다’ 를 참고하여 작성되었습니다.

You Might Not Need Redux

원문: Medium