Redux(이하 리덕스)는 Reducer + Flux를 의미하며 어플리케이션의 스테이트 관리를 더욱 정교하게 하도록 도와주는 라이브러리 중의 하나이다. 이는 로컬에서 존재하던 스테이트를 별도의 컨테이너에 보관하여 다른 곳에서도 접근 할 수 있게 해주는 역할을 한다. 즉, 어플리케이션의 크기가 매우 크더라도 리덕스를 이용하면 스테이트를 아주 효과적으로 관리 할 수 있다.
예를 들자면, 리액트를 이용해 앱을 구현한다고 가정하자. 하위 컴포넌트에서의 변화로 인해 상위 컴포넌트의 스테이트가 바뀌어야하는 시스템이라면 우린 스테이트(setState)를 프랍스로 내려줘서 사용을 하여야한다. 만약, 앱의 크키가 너무 커서 많은 컴포넌트를 거쳐서 전달해야 한다면 이는 굉장히 복잡하고 관리가 힘들 것이다.
여기서 리덕스는 스테이트를 별도의 위치에 저장을 하여 스테이트를 내려주기위한 복잡한 과정을 생략하고 필요한 곳에서 꺼내어 사용할 수 있게 해준다.(실제로 리액트와 리덕스는 별개의 개념이지만 리액트는 리덕스를 사용하기에 굉장히 적합한 프레임워크이다.) 이러한 변화는 SPA의 구현을 더욱 편하게 해줄뿐만 아니라 유지 보수에도 용이하다.
리덕스는 Flux 구조를 계승받았고, 오히려 능가하는 퍼포먼스를 보여준다.
여기서 Flux 구조는 스테이트를 다루기위한 패턴중의 하나로 단방향 데이터 흐름을 가지고 있으며 네가지의 필수 요소(Action, Dispatcher, Store, View)를 동반한다.
View는 Dispatcher와 Store를 통해 Action을 발생 시켜 Store안의 state가 변화가 생기고 그 결과 View의 변화를 볼 수 있다.
예를 들어보면, 리액트는 View를 만들어 내고 유저는 그것을 통해 상호작용(정보를 입력하고 버튼을 클릭하는 것과 같은/ 단방향 흐름 시작)하여 Action을 만들어낸다. Action은 필요한 정보를 캡슐화 하여 Store의 state를 업데이트 하려 하는데 그 과정에서 Dispatcher가 그역할을 대신한다. 그리고 Store에 업데이트된 정보는 다시 View를 통해 보여진다.(단방향 흐름 종료)
그럼 redux와 flux구조의 다른점은 무엇일까? 리덕스는
View -> Action/Dispatch -> Reducer(s) -> Store -> View
위와 같은 구조로 이루어져있다. 특징은 Flux와는 다르게 single store를 가지고 있으며, 위 흐름에서 볼 수 있듯이 Reducer가 있는 걸 볼 수 있다.
Action으로 부터 정보를 받아와 정보가 Dispatch에게 전달되고 Dispatch는 Reducer 를 호출하여 "reduce" (축약?/ 함수를 이용한) 하여 새로운 스테이트로 만들어 저장한다. Reducer는 여러개가 될 수 있다.
위 모양에서의 내가 생각한 장점은 Store가 하나라는 점에서 정보가 분산이 되지않고 Reducer가 여러개라는 점에서 하나의 Store로 여러종류의 정보를 관리할 수 있는게 아닌가 생각한다.
(참고: https://www.robinwieruch.de/react-redux-tutorial#actions)