Redux 개요
Flux 패턴
애플리케이션을 구현해 본 대부분의 개발자라면 MVC라는 용어를 접해 본 경험이 있을 것입니다.
MVC 패턴이란 Model에 데이터를 저장하고, Controller를 사용하여 Model의 데이터를 관리하는 소프트웨어 디자인 패턴의 하나입니다. 이러한 MVC 패턴에서는 사용자가 View를 통해 데이터를 입력하면 View에서도 Model를 업데이트 할 수 있기 때문에 데이터가 양방향으로 전달될 수 있습니다.
하지만 이렇게 구현된 프로젝트는 프로젝트의 규모가 커질수록 수많은 Model과 View가 생성되고, 이때 Model의 상태에 변화가 생길 경우 Model과 View 사이에 엄청난 양의 데이터가 양방향으로 전달되게 됩니다. 이로 인해 데이터의 흐름을 예측하기가 점점 힘들어지고, 수많은 버그를 발생시키는 원인이 됩니다.
[ MVC 패턴 ]
이러한 문제를 해결하기 위해 2014년 페이스북에서는 Flux 패턴이라는 새로운 아키텍처를 제안합니다.
Flux 패턴은 사용자 입력을 기반으로 Action을 생성하고, 이를 Dispatcher에 전달하여 Store의 데이터를 변경한 뒤 View에 반영하는 단방향의 데이터 흐름을 가지는 소프트웨어 아키텍처입니다. Flux 패턴으로 구현된 프로젝트는 데이터가 단방향으로만 전달되기 때문에 데이터의 흐름을 파악하기가 용이하고, 그 결과를 쉽게 예측할 수 있다는 장점을 가집니다.
[ Flux 패턴 ]
이러한 Flux 패턴에 Dan Abramov이라는 개발자가 Reducer를 결합하여 만든 것이 바로 우리가 이번 장에서 살펴 볼 리덕스(Redux)입니다.
Redux란?
우리는 앞서 컴포넌트 내에서 유동적으로 값을 관리할 수 있는 데이터인 state에 대해 알아보았으며, prop을 통해 React 컴포넌트 간에 데이터를 전달하는 방법도 살펴보았습니다.
하지만 애플리케이션의 규모와 복잡도가 증가할수록 컴포넌트끼리 state를 공유해야 할 경우 수많은 컴포넌트를 복잡하게 거쳐야만 그 값을 전달할 수 있게 됩니다. 또한, 필요에 따라 state를 비동기적으로 변경해야 할 경우도 많아지게 되었습니다. 따라서 state를 보다 효과적으로 관리할 수 있는 방법의 중요성이 대두되었으며, 이렇게 등장한 여러 상태 관리 라이브러리 중 하나가 바로 Redux입니다.
Redux는 현재 많은 개발자들이 상태 관리를 위해 즐겨 사용하고 있는 자바스크립트 상태 관리 라이브러리입니다. Redux를 사용하면 state 관리 로직을 컴포넌트와 분리시킴으로써 효율적으로 관리할 수 있게 되며, 컴포넌트끼리 state를 공유할 때 여러 컴포넌트를 거쳐 prop를 복잡하게 전달(Props Drilling)하지 않아도 손쉽게 값을 전달할 수 있게 됩니다.
Redux의 동작 원리
Redux는 Store라는 전역 상태 저장소를 통해 state와 Reducer를 저장합니다.
Redux는 애플리케이션 하나 당 하나의 Store만을 생성하며, 유용한 몇 가지 내장 함수를 같이 제공합니다. 각 컴포넌트들은 이러한 내장 함수들을 사용하여 Store의 데이터에 접근하고 변경을 요청할 수 있습니다.
Store를 변경하기 위한 로직을 저장하는 곳이 바로 Reducer입니다.
Reducer는 Flux 패턴에는 없는 Redux만의 고유한 개념으로 현재 state와 Action을 인수로 전달 받아 Store에 접근하고, 전달 받은 Action을 참고하여 새로운 state를 만들어 반환합니다.
이러한 Reducer를 원하는 조건에 따라 호출하는 것이 바로 Action입니다. state에 어떠한 변화가 필요할 때 Action을 발생시킴으로써(Dispatch) Reducer에 전달합니다.
마지막으로 Dispatch와 함께 Store의 내장 함수 중 하나인 subscribe를 통해 Action이 Dispatch 될 때마다 인수로 전달한 함수를 호출하도록 설정할 수 있습니다.
[ Redux 동작 원리 ]
Redux에서 state를 관리하는 작업의 흐름은 다음과 같이 진행됩니다.
1. 사용자가 UI를 통해 컴포넌트 내에 존재하는 이벤트를 호출합니다.
2. 이벤트와 연결된 액션 생성 함수(Action Creator)가 호출됩니다.
3. 액션 생성 함수에서 생성된 Action이 호출됩니다.
4. 호출된 Action이 Reducer로 전달(Dispatch)됩니다.
5. Reducer에서 Dispatch 된 Action에 따라 state 값을 변경합니다.
6. 변경된 state가 렌더링되어 UI에 표시됩니다.
Redux의 세 가지 원칙
이러한 Redux에서는 반드시 준수해야만 하는 세 가지 원칙이 있습니다.
1. 하나의 애플리케이션 안에는 하나의 Store만 사용해야 합니다. 이렇게 함으로써 서버로부터 가져온 state가 직렬화(serialization)된 채 전달될 수 있으며, 클라이언트 측에서는 이를 추가적인 코드 없이도 곧바로 사용할 수 있습니다. 또한, 디버깅도 용이해 집니다.
2. state는 읽기 전용입니다. state를 변화시키는 유일한 방법은 Action을 전달하는 것 뿐입니다. 이를 통해 모든 state 변화를 중앙에서 관리할 수 있으며, state 변경에 대한 추적이 용이해 집니다.
3. state의 변화를 일으키는 Reducer는 순수 함수로 작성되어야 합니다. Reducer는 현재 state와 Action을 전달 받아 다음 state를 반환하는 순수 함수입니다. 즉, 이전 state를 변경하는 것이 아니라 새로운 state 객체를 생성하여 반환하는 것임을 잊지 말아야 합니다.
Redux의 필요성
Reudx를 사용하면 전역 상태 관리를 매우 효과적으로 수행할 수 있게 됩니다. 하지만 이러한 전역 상태 관리는 Redux 뿐만 아니라 Mobex, Recoil, Zotai 등 다른 상태 관리 라이브러리를 대신 사용할 수도 있으며, React의 Context API를 통해서도 충분히 동일한 작업을 수행할 수 있습니다.
또한, Redux를 사용하게 되면 단 하나의 state를 바꾸기 위해 요청을 전달하는 Action과 상태를 바꿔주는 Redux를 생성해야 하는 등 추가적인 코드의 양이 늘어나게 됩니다.
따라서 상태 관리를 위해서는 반드시 Redux를 사용해야 한다는 것이 아니라 해당 프로젝트의 특징과 확장성 등을 충분히 고려하여 Redux의 도입 여부를 결정하는 것을 권장합니다.
