[처음 만난 리덕스] 1. Redux 소개

리덕스(Redux) 탄생 과정

SPA 등장으로, 웹사이트의 규모가 커짐

→ 상태 관리의 복잡도 증가
(서버로부터 받아온 데이터, 로컬 데이터, UI 컴포넌트의 상태 등..)

언제 어디서 어떻게 상태(state)가 업데이트 되는지 파악하기 힘들어짐

 

상태 업데이트의 원인을 파악할 수 없다면,

버그 재현 및 수정이 어려움

 

상태 관리만을 위한 리덕스(Redux) 등장!

 

 

Flux 아키텍처

: 단방향 데이터 흐름을 활용한 리액트용 애플리케이션 아키텍쳐

= 데이터의 흐름을 정의한 하나의 방법

 

 

• 액션(Action): 데이터 흐름에 변화를 주기 위한 어떤 동작이 발생한 것
• 디스패처(Dispatcher): 액션을 발송하는 역할 (액션의 수신자: 리덕스)
• 스토어(Store): 데이터를 저장하는 공간
• 뷰(View): 스토어에서 가져온 데이터를 보여줌
  *뷰에서 또다른 액션이 발생하면 단방향 동일한 흐름으로 처리됨

 

플렉스(Flux)와 리덕스(Redux)의 관계

= Redux implements Flux (리덕스가 플렉스를 구현)

• 플렉스(Flux): 데이터의 흐름을 정의하는 패턴
                        (추상적 개념을 구조화 시켜 정의)
• 리덕스(Redux): 플렉스라는 아키텍처를 실제로 구현한 구현체
                           (Flux를 곧바로 사용할 수 있게 한 라이브러리)

 

 

리덕스의 세 가지 원칙★

1. 단 하나의 진실의 원천 (Single source of truth)
   : 진실이라고 여겨지는 값이 여러 곳이 아닌 단 한 곳에만 존재해야 한다.
   - 리덕스 에서는 애플리케이션의 모든 상태들을 Redux 스토어(Store)에 저장
   - 이 Redux Store가 Single source of truth
   - 어떤 상태의 값의 변경을 확인하고자 할 때 Store 내부에서 해당 상태의 값의 변화만 확인하면 됨
2. 상태 값은 읽기 전용 (State is read-only)
   : 사전에 정의해둔 어떤 상황이 발생했을 경우에, 사전에 정해진대로만 상태를 변경할 수 있음!
   - 모든 상태의 변화가 단 한곳에서 정해진 상황과 규칙에 따라 발생
3. 변화는 순수 함수들을 통해 이뤄져야 함 (Changes are made with pure functions)
   : 모든 Reducer는 pure function이어야 한다.
   - 순수함수: 입력값을 변경하지 않으며, 같은 입력값에 대해 항상 같은 출력값을 리턴함

 

Redux의 세 번째 원칙

 

리덕스의 데이터 흐름

 

 

상태 관리를 위해 꼭 리덕스여야만 할까?

- 다른 상태관리 라이브러리들

: MobX, Recoil, ZUSTAND, Jotai 등

 

하지만, 리덕스가 압도적으로 상위권을 유지하고 있기에

리덕스는 필수적으로 사용해보아야 한다.