개인 프로젝트가 끝나고 나서, 이번에는 상태 관리 라이브러리 중 압도적인 사용자를 보유한 Redux를 공부하고 있다. 포스팅을 통해 공부 내용들을 기록해보려 한다.
1. Redux의 탄생 배경
SPA(Single Page Application)이 등장한 이후 다양한 요구사들을 적용하면서 웹사이트의 규모가 점점 커지게 되었다. 규모가 커진만큼 관리해야 state(상태)들이 많아지면서, 상태관리의 복잡도도 크게 증가하게 되었다.
대표적으로 리액트의 관점에서 위 그림과 같이 수많은 컴포넌들과 그 안에 state들이 많아지면서 상태관리의 복잡도가 증가한 것이다. 이러한 결과로 가장 큰 문제는 언제 어디서 어떻게 상태가 업데이트 되는지 파악하기 힘들어 졌다는 것이었다. 개발자들이 이러한 과정을 파악하는데 어려움을 겪으면서 버그의 원인을 찾고 수정하는데 시간이 오래 걸렸고, 새로운 기능을 추가하는 것도 힘들어졌다.
그래서 이런 문제를 경험한 개발자들은 '수많은 상태들을 어떻게 효과적으로 관리할 것인가?'를 떠올렸고, 이러한 결과로 상태 관리만을 위한 기술인 Reudx가 등장하게 됩니다.
2. Redux란?
Redux는 JavaScript(자바스크립트) 앱을 위한 상태관리 라이브러리이다.
3. Flux Architecture
Redux는 Flux Architecture를 실제로 구현한 라이브러리라는 의미이다.
Flux는 공식 Github repository에서 단방향 데이터 흐름을 활용한 리액트용 어플리케이션 아키텍처라고 정의하고 있다. 단방향(unidirectional)으로 하나의 방향만 존재한다는 의미이다.
데이터 흐름을 아래 그림을 보면 같이 단방향으로 흐른다는 것이 무슨 의미인 쉽게 이해할 수 있다.
1. Action에서 데이터 흐름에 변화를 주기 위한 어떤 동작이 발생하고, 발생한 Action을 Dispatcher가 받는다.
2. Dispatcher는 Action이 발생했다는 것을 Redux에게 알린다.
3. Dispatcher를 통해 변화된 데이터가 Store에 저장된다.
4. Store에 가져온 데이터를 View를 통 보여준다.
5. View에서 또 다른 Action이 발생하면 위와 같은 흐름을 반복해서 단방향으로 처리한다.
4. Three Principle of Redux
Flux 패턴이 반영된 Redux의 세 가지 원칙이 있는데, Redux를 이해하고 사용하면서 매우 중요한 원칙들이다.
💡 1. Single source of truth (단 하나의 진실의 원천)
- Redux는 모든 상태들을 Store에 저장하는데, 모든 상태들이 이 하나 뿐인 데이터 공간인 Store에 저장된다는 것
- 동일한 데이터는 항상 같은 곳에서 가져온다
💡 2. State is read-only (상태값은 읽기 전용)
- 상태값은 읽을 수만 있고 변경할 수 없다
- 사전에 미리 변경할 상황과 변경될 규칙을 정의해 어떤 상황이 발생했을 경우에 사전에 정해진대로만 상태를 변경할 수 있다. 이러한 결과로 정해진 상황과 규칙에 따라 상태 변경이 일어나기 때문에 상태를 변경할 때마다 어떤 목적과 어떤 값으로 변경하는지 쉽게 파악이 가능하다
💡 3. Changes are made with pure functions (변화는 순수한 함수들을 통해 이루어져 한다)
- 상태의 변화를 일으키는 모든 함수는 입력값(input)을 변경하지 않으며, 값은 입력값에 대해서는 항상 같은 출력값(output)을 리턴해야 한다는 것이 Pure Function
- Redux에서 상태의 변화를 일으키는 함수를 Reducer라고 부르는, 모든 Reducer는 Pure Function이어야 한다는 것
참고 :
처음 만난 리덕스 (Redux): Three Principles of Redux - FrontOverflow
상태관리의 기초 개념과 함께 리덕스의 기초를 탄탄하게 다질 수 있습니다.
www.frontoverflow.com
