why redux?
개발을 하다보면 상태관리가 필요해지는 경우가 많다.
상태란, 동적으로 변경되는 데이터를 의미한다. 이때 변경될 상태는 크게 두가지로 분류할 수 있다.
1. 로컬 상태
상태값이 특정 컴포넌트 내에서 귀속되는 데이터를 의미한다. 해당 데이터는 오롯이 컴포넌트 내부에만 영향을 미치고 다른 컴포넌트에는 영향을 주지 않는다.
- 전역 상태
상태값이 다수의 컴포넌트에서 공유되야 하는 상황을 의미한다. 한 컴포넌트의 변경이 다른 컴포넌트에서 presentation을 할 때 영향을 미칠 수 있는 경우, 이 상태는 서로 공유되어야 한다.
전역 상태의 개념에서부터, Single source of truth라는 개념이 나온다.
Single source of truth란, 서로 공유되는 상태를 가지고 있을 때 그 상태는 오로지 동일한 출처에서 나와야 한다는 것이다.
또한, 모든 컴포넌트들 (자식 포함) 이 동일한 정보를 가지고 있으려면, 이를 전달할 방법도 역시 필요한데
기존처럼 props를 이용해서 모든 컴포넌트에 전달한다면 컴포넌트들간에 prop이 너무 많아지고, 느슨한 결합을 해칠 가능성이 높아진다
리덕스는 상태관리 툴로서, 이런 전역적인 상태를 관리하기 위한 도움을 주는 툴이다
what redux?
리덕스는 크게 3가지 원칙에 따라 flux 패턴을 이용하여 구현이 되고 있다.
1. single source of truth = 공유되는 상태값은 동일한 출처에서 나와야 한다
2. readonly state = 상태값은 객체지향적 개발처럼 특정 메서드(액션) 이 아니면 변경할 수 없고 읽을수만 있다
3. pure function = 상태를 변경시키는데 사용되는 함수는 오로지 상태변경을 위한 액션객체를 리턴하는 순수함수여야 한다. (동일결과)
이런 원리를 통해 단방향 데이터 흐름을 실행하면 혼선 없이 호율적인 상태관리와, 예측가능성이 높아진다.
기존에 패턴은 MVC 모델을 통해 상태관리를 하곤 했다.
- model => 데이터의 형태에 대한 규정과 구조
- view => 사용자에게 보여지는 내용
- controller => 변경되는 데이터를 통해 모델과 view를 업데이트하는 구조
해당 MVC 패턴의 가장 큰 문제는 양방향 데이터 흐름이기 때문에 어플리케이션의 규모가 커지면 커질수록 복잡도가 기하급수적으로 늘어난다는 것에 있다
하지만 redux의 경우, Flux 패턴을 이용하여 단방향으로만 업데이트가 가능하기 때문에, 코드의 추적이 용이하다
업데이트는 액션 객체를 받은 디스패쳐가 전달하는 내용에 의해 store이 변경되는 구조이고,
기존의 controller과 view를 결합하여 동일한 관심사를 보이도록 하였다.
즉, 어차피 데이터가 업데이트가 되면 view가 달라져야 하는 것이므로, controller의 행위가 그대로 view와 연동되도록, 즉 리 랜더링이 되도록 하는 것이다.
