TIL) 리덕스 기초, 리덕스 작동 방식 정리, 왜 리덕스를 배울까? 왜 리덕스가 리액트 생태계에서 중요하지? 리덕스를 리액트에서 어떻게 사용하지?

 

배운점 

1. 왜 리덕스를 배울까? 

2. 왜 리덕스가 리액트 생태계에서 중요하지?

3. 리덕스를 리액트에서 어떻게 사용하지?

 

 

---

왜 리덕스를 배울까?

 

리덕스는 크로스 컴포넌트 또는 앱 와이드 상태를 위한 상태 관리 시스템이다. 

우리가 상태, 즉 우리 애플리케이션을 변경학 화면에 표시하는 데이터를 관리하도록 도와준다. 

 

리덕스는 우리가 그런 데이터를 다수의 컴포넌트나 심지어는 앱 전체에서 관리하도록 도와준다. 

 

앞에서 배운 state를 3가지로 구분할 수 있다. 

 

 

1. local state : 데이터가 변경되어서 하나의 컴포넌트에 속하는 UI에 영향을 미치는 상태. (useState() 나 useReducer() 사용)

2. cross-component state : 하나의 컴포넌트가 아니라 다수의 컴포넌트에 영향을 미치는 상태. (useState() 나 useReducer() 사용 && prop을 주변에 넣어주어야 한다. (prop 체인 구축 => prop 드릴링))

3. app-wide state : 다수의 컴포넌트가 아니라 애플리케이션의 모든 컴포넌트에 영향을 미치는 상태. ex 사용자 인증 (useState() 나 useReducer() 사용하고, props 전체 주변의 함수를 업데이트해서 그걸 관리할 수도 있다. )

 

 

크로스 컴포넌트와 앱 와이드 state에서 데이터를 넣고 전체 props 함수를 업데이트 하는 것은 번거로울 수 있다.

 

크로스 컴포넌트와 앱 와이드 state를 단순화 할 수 있다. 

 

=> 이걸 리액트 컨테스트가 보완해주는 역할을 한다. 

리액트 컨텍스트를 쓰면 prop 체인이나 prop 드릴링을 하지 않을 수 있고, 대신에 Context와 ContextProvider 컴포넌트를 중심으로 상태를 관리할 수 있다. 

 

---

왜 리덕스가 리액트 생태계에서 중요하지?

이렇게 다수의 컴포넌트에 영향을 미치는 state를 관리하는 리액트 컨텍스트가 있는데 왜 리덕스까지 공부해야할까??

리액트 컨테스트는 잠재적인 단점이 있기 때문이다!

 

단점 1. 리액트 컨텍스트를 사용하면 설정이 아주 복잡해질 수 있고, 리액트 컨텍스트를 이용한 상태 관리가 복잡해질 수 있다.

다수의 컴포넌트나 전체 앱에 영향을 미치는 많은 다양한 state가 있다. 그래서 그런 state를 관리하기 위해 구축한 ContextProvider 컴포넌트가 많이 존재하게 된다. 

그럼 아래처럼 됌... 👇

 

단점 2. 테마를 변경하거나 인증 같은 저빈도 업데이트에는 성능이 좋지만, 데이터가 자주 변경되는 경우에는 성능이 좋지 않다. (유동적인 state 확산을 대체할 수 없다. )

이에 반해 리덕스는 유동적인 상태 관리 라이브러리다. 

 

하지만 소형, 중형 애플리케이션 같은 경우에는 이런 단점이 상관 없을 수도 있다. 

 

아무튼 리덕스는 리액트 컨텍스트의 대안이다. 

 

---

리덕스를 리액트에서 어떻게 사용하지?

 

리덕스는 애플리케이션에 있는 하나의 중앙 데이터(state) 저장소이다. 

 

저장소에 데이터를 저장해서 컴포넌트 안에서 그걸 사용할 수 있다. 

예를 들어, 사용자의 인증 상태가 변경되는 등 거기 있는 데이터가 변경되면 우리는 컴포넌트에서 그걸 인지해서 그에 맞춰 대응하고 UI를 업데이트하길 원한다.

 

데이터 받아오는 방법

1. 이 컴포넌트를 위해 우리 중앙 저장소에 대한 구독을 설정한다. (subscription)

2. 컴포넌트가 저장소를 구독하고 데이터가 변경될 때마다 저장소가 컴포넌트에 알려준다.

3. 그럼 컴포넌트는 필요한 데이터를 받게 되고, 그걸 사용할 수 있다. (리덕스 저장소의 일부는 받는 것이다. ) ex) 현재의 인증 상태 같은 것

 

데이터 변경하는 방법

**컴포넌트는 절대로 중요하지 않고, 절대로 저장된 데이터를 직접 조작하지 않는다. **

그래서 구독을 하는 것이고, 데이터는 절대로 반대 방향으로 흐르지 않는다!! (적어도 직접적인 데이터 흐름은 그렇다.)

컴포넌트는 저장소에 있는 그 데이터를 직접 조작하지 않는다. 대신, 리듀서라는 개념을 이용한다. 

 

리듀서 함수를 설정해야 한다. 이 함수는 변형을 담당한다. (mutates store data)

**여기서의 리듀서 함수는 useReducer 훅과는 다르다**

리듀서 함수는 입력을 받아서 그 입력을 변환하고 줄이는 함수이다. ex) 숫자로 된 리스트를 그 숫자들의 합으로 줄일 수 있다. 

리듀서 함수는 입력을 변환해서 새로운 출력, 새로운 결과를 뱉어낸다. => 일반적인 프로그래밍 개념

 

useReducer 는 훅이 사용하고 리듀서 함수는 리덕스도 사용한다. 

 

 

컴포넌트와 그 리듀서 함수를 연결하는 방법

 

어떤 컴포넌트의 버튼을 클릭하면 그게 데이터 변경을 트리거 한다. 이걸 어떻게 연결할까??

컴포넌트가 액션을 발송한다. (dispatch)

그래서 컴포넌트가 어떤 액션을 트리거한다고 말할 수 있다. 이런 액션은 단순한 자바스크립트 객체고, 그게 리듀서가 수행해야 할 작업을 설명한다. => 리덕스는 그 액션을 리듀서로 전달하고 원하는 작업에 대한 설명을 읽게 된다. 이어서 그 작업을 리듀서가 수행하게 된다. 

 

**리덕스 작동 방식 총 정리**

컴포넌트가 액션을 발송하고 그 액션에는 수행해야 할 작업이 설명되어 있다.

하지만 그걸 직접 하지 않고, 액션들을 리듀서로 전달해서 그 액션이 원하는 걸 리듀서가 하게 된다.

그리고 나서, 리듀서는 새로운 상태(state)를 뱉어내고 그게 실제로 그 중앙 데이터 저장소의 기존 상태를 대체하게 된다.

그리고 그런 과정이 일어나고 데이터 저장소의 상태가 업데이트 되면, 구독 중인 컴포넌트가 알림을 받게 되고, 컴포넌트는 UI를 업데이트 할 수 있게 되는거다. 

 

 

 

😃 잘못된 개념 전달이 있다면 댓글 부탁드립니다. 저의 성장에 큰 도움이 됩니다🤓