1. 리덕스의 전역상태관리

<전역상태관리>

전역 상태관리는, 말 그대로

전역적(Global, 全域的) 으로 상태를 관리한다는 의미이다.

 

 

<리액트에서의 상태관리>

기본적으로 바닐라 리액트에서는 부모-자식 트리구조의 컴포넌트 틀에서 상위->하위 로 상태값을 전달하여 관리하게 되어있다.

이러한 경우, 자식 컴포넌트(하위) 에서 상태값을 전달받아야 하는 컴포넌트가 분리되고 많아질수록, 상태값 관리가 복잡해진다.

예를 들어, 

최하위에 있는 컴포넌트Z 에서 필요한 상태값이, 최상위에 가까운 부모컴포넌트A 에 있다고 생각해보자.

최하위에 있는 컴포넌트가 그 상태값을 받아오려면,

컴포A(필요한 상태값을 가진) --> 하위컴포B->  하위컴포C --> 하위컴포D --- ......... ---> 컴포Z(필요한 상태값을 받는)

위와 같이 몇개의 컴포넌트가 될지 모르는 상황에서도 모든 컴포넌트를 통해서만, 상태값을 받아와야하는 상황이 생긴다.

일반적으로 이런 경우를, 드릴링 (Drilling) 이라고 한다.

-> 해결 방법은 크게 2가지로 '전역관리 상태 라이브러리 사용' , ' children'을 사용한 리팩토링 이 있다.

 

 

<전역상태관리 라이브러리>

위와 같은 상태관리의 불편함(?)을 해소하기 위해,

상태관리를 보다 용이하게 해주는 것이, 전역상태관리 라이브러리 이다.

일반적으로 redux, mobX, recoil 등이 있으며,

redux가 현재 가장 많이 사용되는 라이브러리인 것으로 알고 있다.

사실 redux는 '리액트의 전역상태관리 라이브러리' 라기보다,

'자바스크립트 앱을 위한 전역상태관리 라이브러리' 라고 하는 것이 더 맞는 표현이긴 하다. 왜냐하면,

리덕스 홈페이지 참조

리덕스에서 그렇게 말하고 있기 때문이다.

그렇다고 해서, 사실 리액트 사용자가 가장 많이 쓰는 전역상태관리 라이브러리 라는 것이 틀린말이 되는 것은 아니다.

(확실한 것은 아니지만, 리덕스를 만든 사람이 리액트팀에 입사? 했다는 얘기를 들은적이 있다)

그만큼 리액트와 합이 잘 맞는다는 것 아닐까 싶다.

 

 

<리덕스 Redux의 상태관리 차이>

그렇다면, 리덕스에서는 전역상태관리를 어떻게 할까.

활용구조를 이해하기 위해서는,

리덕스에서의 액션, 디스패치, 액션생성함수, 리듀서, 스토어, 구독 이라는 개념을 알아야 상세히 이해할 수 있지만,

우선은 어떤 원리로 기존의 바닐라 리액트와 다르게 전역상태관리가 가능한 것인지를 먼저 알아보자.

리덕스 홈페이지 참조

내가 가장 이해하기 쉬웠던 포인트는 위 그림에서의 '중앙화된' 이다.

기존에는 트리구조의 형태처럼 수직적으로 상태값을 전달하고 받아야하는 통로밖에 없었다고 한다면,

이 '중앙화된' 이라는 캐치프레이즈에서 알 수 있듯,

상태값을 주고받는 통로가 중앙화 되어 기존의 수직구조를 벗어난 개념임을 짐작할 수 있다.

리덕스 플로우 출처 : https://medium.com/@ca3rot/%EC%95%84%EB%A7%88-%EC%9D%B4%EA%B2%8C-%EC%A0%9C%EC%9D%BC-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-%EC%89%AC%EC%9A%B8%EA%B1%B8%EC%9A%94-react-redux-%ED%94%8C%EB%A1%9C%EC%9A%B0%EC%9D%98-%EC%9D%B4%ED%95%B4-1585e911a0a6

위의 리덕스 플로우를 다 이해하기 위해서는 

앞서 이야기한, 액션, 디스패치 등등의 개념을 알아야하지만,

지금은 위 플로우에서 Store 와 Connected Component 만 보자.

이 두 위치에 초점을 맞춰 전체 플로우를 보면, 

특정 컴포넌트에서 필요한 상태값을 가져오는데 있어서,

트리구조상의 다른 컴포넌트들의 개입이 전혀 없음을 확인할 수 있다.

 

정리하자면,

기존의 상태관리와의 가장 큰 차이는, 상태값을 주고받는 구조의 차이 라고 이해할 수 있었다.

물론, 리액트에서 제공하는 Context API를 활용해서 기존의 상태관리를 다소 간편하게(?) 접근할 수 있는 방법도 있지만,

상태값 자체를, 별도의 외부(기존의 트리구조 밖) 스토어를 통해 주고받을 수 있다는 점에서,

리덕스의 큰 특징을 이해할 수 있었다.

 

이렇게 기존 트리구조를 벗어난 위치에서 상태값을 관리할 수 있게 되면서,

우선 드릴링의 문제를 해소할 수 있게 된다. (아마 이로 인해 전체적인 부하나 리소스 효율도 더 좋아질 것이다)

또, 특정 상태값을 찾고 관리할때 각각의 컴포넌트들을 찾아야하는 것이 아니라,

실제 상태값이 필요한 컴포넌트와 리덕스 스토어에 먼저 집중할 수 있게 되어,

리액트의 활용도도 동시에 높아지는것이 아닌가 싶다. 

 

 

 

 

<추가로 더 알아보면 좋을 것들>

리덕스의 활용구조 (액션, 디스패치, 액션생성함수, 리듀서, 스토어, 구독)

Context API , 그리고 리덕스와의 차이

바닐라 리액트에서 children을 활용한 리팩토링

미들웨어의 종류와 기능