[ Redux ] Redux 란 무엇인가?

Redux 란?

• Redux 란 JavaScript 상태 관리 라이브러리 중 하나입니다. (Flux 아키텍처를 구현한 라이브러리)
• Redux = React + Flux Pattern

Flux Pattern 이란?

Flux Pattern 은 MVC 패턴의 단점을 보완하기 위해 Facebook 에서 만든 아키텍처입니다.
MVC 패턴은 Model 에서 데이터가 정의되고, View 에서 데이터를 보여주고, Controller 에서 데이터를 조작합니다.
그런데 만약 어플리케이션이 규모가 커져서 이런 구조를 사용하게 되면, 데이터의 흐름이 복잡해지고, 데이터의 흐름을 추적하기 어려워집니다.
이러한 문제를 해결하기 위해 Flux Pattern 을 사용합니다.

Flux Pattern 의 구조

• Action : Action이란 데이터를 변경하는 행위로서 Dispatcher에게 전달되는 객체를 말합니다. Action creator 메서드는 새로 발생한 Action의 타입(type)과 새로운 데이터(payload)를 묶어 Dispatcher에게 전달합니다.
• Dispatcher : Dispatcher는 모든 데이터의 흐름을 관리하는 중앙 허브입니다. Dispatcher에는 Store들이 등록해놓은 Action 타입마다의 콜백 함수들이 존재합니다. Action을 감지하면 Store들이 각 타입에 맞는 Store의 콜백 함수를 실행합니다.
• Store(Model) : Store는 상태 저장소로서 상태와 상태를 변경할 수 있는 메서드를 가지고 있습니다. 어떤 타입의 Action이 발생했는지에 따라 그에 맞는 데이터 변경을 수행하는 콜백 함수를 Dispatcher에 등록합니다.
• View : View는 리액트 컴포넌트로 생각하면 됩니다. Store에서 View에게 상태가 변경되었음을 알려주면 최상위 View(Controller View)는 Store에서 데이터를 가져와 자식 View에게 내려보냅니다. 새로운 데이터를 받은 View는 화면을 리렌더링합니다. 또한 사용자가 View에 어떤한 조작을 하면 그에 해당하는 Action을 생성합니다.

Redux 사용 이유

• 전역 상태 관리를 위해 사용합니다.
• 전역 상태 관리를 해주는 이유는 props 를 계속해서 전달해주는 것이 번거롭기 때문입니다.
• depth 가 깊어질수록 props drilling 이 발생해서 코드를 추적하기 어려워집니다.

Redux 장점

• 단방향 데이터 흐름을 제공합니다. (데이터의 흐름을 예측하기 쉽습니다.)
• 상태의 중앙 집중화를 제공합니다. store 에서 관리하기 때문에 상태를 관리하기 쉽습니다.
• 상태를 읽기 전용으로 취급합니다. 상태가 읽기 전용이기 때문에 이전 상태로 돌아가기 위해 undo/redo 기능을 구현하기 쉽습니다.

Redux 단점

• Boilerplate 코드가 많습니다. 간단한 앱이라도 Redux 를 사용하면 코드가 많아집니다.
• 상태를 읽기 전용으로 취급하지만, 실제로 읽기 전용으로 취급하지 않기 때문에 실수로 상태를 변경할 수 있습니다.
• 불변성 개념을 지켜야 해서 state라는 객체를 매번 새로 만들어야 합니다.

Context API vs Redux

• Context API 와 Redux 는 둘 다 같은 목적을 가지고 있습니다.
  단, 다른 방식으로 작동하는 라이브러리입니다.
  이 둘의 차이점을 알아보겠습니다.

Context API

context를 이용하면 단계마다 일일이 props를 넘겨주지 않고도 컴포넌트 트리 전체에 데이터를 제공할 수 있습니다.

• Context API 는 상태 관리 라이브러리가 아니고, props 의 하향식 전달을 대체하는 방법입니다.
• React 를 사용하면, 자동으로 제공하는 기능이기에 별도의 설치가 필요 없습니다.
• 단 context 의 provider 는 value 값이 변할 때마다 이 값을 사용하는 컴포넌트들이 리렌더링 됩니다.
  context 를 상태값과 액션값으로 나누면 이 문제는 해결이 가능하지만, provider 지옥이 발생할 수 있습니다.

Redux

Redux 는 JavaScript 애플리케이션을 위한 예측 가능한 상태 컨테이너입니다.

• Redux 는 중앙 집중화된 상태 관리 라이브러리입니다.
• 단방향 데이터 흐름을 가진 라이브러리이기 때문에, 컴포넌트의 상태 예측이 가능하고 디버깅이 쉽습니다.
• Boilerplate 코드가 많습니다. 간단한 앱이라도 Redux 를 사용하면 코드가 많아집니다.
• 또 읽기 전용으로 취급하지만 실제로 읽기 전용으로 취급하지 않기 때문에 실수로 상태를 변경할 수 있습니다.

차이점

1. Middleware
   • 리덕스에는 미들웨어(middleware)라는 개념이 있습니다. 리덕스로 상태 관리를 할 때 Reducer 함수를 사용하는데, 미들웨어를 사용하면 액션 객체가 리듀서에 처리되기 전에 우리가 원하는 작업을 수행할 수 있습니다.
   • 보통 비동기 작업을 처리 할 때 많이 사용됩니다.
2. Hooks
   • Context API 를 사용할 때, Context 도 만들고 Provider 도 만들고 Consumer 도 만들어야 했습니다. 이러한 작업을 편하게 해주는 것이 Custom Hooks 입니다.
   • Redux 에서는 connect 함수를 사용하면 간단하게 상태를 props 로 받아올 수 있으며, useSelector 라는 Hook 을 사용하면 상태를 조회할 수 있습니다.
3. 하나의 커다란 상태
   • Context API 를 사용하여 props 를 전달할 때, 기능별로 나누어서 전달해야 했습니다. 하지만 Redux 는 하나의 커다란 상태를 가지고 있기 때문에 하나의 커다란 state 객체에 넣어서 관리할 수 있습니다.

Redux 3원칙

• Redux 는 3가지 원칙을 가지고 있습니다.

1. Single source of truth (진실은 하나의 근원으로부터)

애플리케이션의 모든 상태는 하나의 스토어 안에 하나의 객체 트리 구조로 저장됩니다.

하나의 스토어(Store) 안에 하나의 객체 트리 구조로 직렬화(serialized)되거나 수화되어(hydrated) 저장되기 때문에 추가적인 코딩 없이도 시간여행, 미들웨어, 저장 및 재사용 등의 기능을 사용할 수 있습니다.

2. State is read-only (상태는 읽기 전용이다)

상태를 변경할 수 있는 유일한 방법은 액션을 발생시키는 것 뿐입니다.

이를 통해서 뷰나 네트워크 콜백에서 결코 상태를 직접 바꾸지 못 한다는 것을 보장할 수 있습니다. 모든 상태 변화는 중앙에서 관리되며 모든 액션은 엄격한 순서에 의해 하나하나 실행되기 때문에, 신경써서 관리해야할 미묘한 경쟁 상태는 없습니다. 또한, 액션을 기록하거나 재생하거나, 상태를 저장하거나 불러오는 등의 작업을 할 수 있습니다.

3. Changes are made with pure functions (변화는 순수 함수로 이루어져야 한다)

액션에 의해 상태 트리가 어떻게 변화하는지를 기술하는 리듀서를 작성해야 합니다.

리듀서는 이전 상태와 액션을 받아서 다음 상태를 반환하는 순수 함수입니다. 이전 상태를 변경하거나 액션을 발생시키는 등의 일을 하지 않습니다.

Reference

• Redux 시작하기
• Redux 3원칙