Redux

리덕스(Redux)를 왜 사용할까

기존 리액트 앱에서는 보통 하나의 루트 컴포넌트(ex. App.js)에서 상황을 관리했다. 즉, 대부분의 경우 루트 컴포넌트를 중간자로 사용해 서로 소통이 되는 상황이다.

A 컴포넌트와 B컴포넌트가 서로 하나의 state를 공유하고 소통을 하려면 App.js를 경유해야만 했다. 이는 위와같은 간단한 트리형태의 리액트 앱이라면 별 문제가 되지않지만 트리의 구조가 복잡화 된다면 문제의 크기는 비례하여 커진다

아까와 같은 단순한 트리구조의 리액트가 아닌 좀더 복잡해져 버린 트리구조로 이루어진 리액트 앱을 살펴보자. 만약 G와 L이 같은 state를 공유한다면 공통된 부모인 App.js를 경유해야 할것이다. 그렇다면 L 컴포넌트까지 B => F => J의 순서대로 state는 상속되어야 할것이고 만약 어딘가에서의 작은 변화는 모든것을 일일히 수정해야 하는 상황이 발생한다. 그리고 보통 이런 상황은 작은 오류를 발생해서 2,3시간씩 허비하는 상황까지 발전한다.

이러한 문제를 리덕스는 해결할 수 있다. 리덕스의 상태관리는 컴포넌트 밖에서 일어난다. 리덕스는 스토어 라는 곳에서 프로젝트의 상태에 관한 데이터들을 담아 놓는다.

이제 G,L 컴포넌트는 Store라는 상태를 저장하는 곳에서 상태를 끌어다 사용할 수 있다.

어떻게 리덕스를 사용하는가

컴포넌트의 스토어 구독

L컴포넌트는 스토어에 구독을 한다. 이 과정에서 특정 함수가 스토어에게 전달이 된다. 후에 스토어의 상태가 변경된다면 전달받았던 함수를 호출해준다.

스토어에 상태 변경하라고 말해주기

G컴포넌트에 어떤 변화가 생겨 상태를 변화해야 할 일이 생겼다. 이럴때 dispatch라는 함수를 이용해 action을 스토어에게 던져준다. 후에 기술하겠지만 리덕스에서 상태는 read-only이고, 상태를 바꿀 수 있는건 action뿐이다. 액션은 상태를 변화할 때 참조할 수 있는 객체이다. 이러한 액션 객체는 필수적으로 type이라는 key를 지니고 있어야 한다.

리듀서를 통해 상태 변화

액션 객체를 받으면 이 액션의 타입에 따라 상태를 어떻게 업데이트 해주어야 할지 정의하는 함수를 리듀서라고 부른다. 이러한 리듀서는 두가지 파라미터를 받는다.

1. state : 현재 상태

2. action : 액션 객체

이 두가지 파라미터를 참조하여 새로운 상태객체를 만들어 반환한다.

상태의 변화가 생기면 구독중인 컴포넌트에게 알림

이렇게 상태에 변화가 생겼다면 이전에 L컴포넌트가 store를 구독할때 전해주었던 listern()함수가 호출된다. 이를 통해 컴포넌트는 새로운 상태를 받게되고, 이를 바탕으로 리렌더링할 수 있다.

리덕스의 3가지 규칙

1. single source of truth

하나의 애플리케이션에는 하나의 스토어가 있어야 한다. 여러개의 스토어를 만들 수도 있다. 보통 특정 업데이트가 빈번하게 일어난다거나 특정 부분을 완전히 분리할때 복수의 스토어가 사용되지만 일반적인 경우는 아니다. 스토어가 여러개 지정되었다면 개발자 도구를 제대로 이용할 수 없다.

2. state is read-only

상태는 읽기 전용이다. react에서도 setState로 상태를 업데이트 해줄때 기존 상태를 변경해주는것이 아닌 새로운 상태를 만들어 교체하는 방식을 사용했다. 리덕스도 마찬가지이다. 리덕스 또한 불변성을 유지해주어야 한다.

3. changes are made with pure functions

변화를 일으키는건 순수한 함수로만 이루어져야한다. 여기서 함수는 리듀서를 의미한다. 리듀서는 다음과 같은 특징을 지닌다.

• 리듀서함수는 이전 상태(state)와 액션객체(action)을 파라미터로 받는다.
• 이전 상태는 건들지 않고 변화를 일으킨 새로운 객체를 만들어서 반환한다.
• 똑같은 파라미터로 호출도니 리듀서는 언제나 같은 결과를 반환해야한다.