📌들어가기 전에
- React에서의 컴포넌트 간 데이터 전달은 기본적으로 단일방향으로 이루어지고
State
Props
이용해 양방향 데이터 전달을 구현할 수는 있다.
- 하지만, 컴포넌트가 많아지고 구조가 복잡해질때 데이터 전달을 하려면 여러 컴포넌트를 거치는 경우도 있고, 코드 구조가 굉장히 복잡해진다. (스파게티 코드가 된다.)
- 따라서 React Document에서 해결방안을 제시해준다.
parent-child 관계가 아닌 컴포넌트에서 데이터 교류는 글로벌 이벤트 시스템 설정을 해라. Flux 패턴은 이것을 해결하기 위한 방법들 중 하나이다.
📌Flux
Flux
라이브러리가 아닌 디자인 패턴이다.
- 기존에 널리 사용되고 있는 MVC 패턴에서 어떠한 Action이 입력되었을 때 Controller가 Model이 가지고 있는 데이터를 조회하거나 업데이트 하고, 이렇게 바뀐 데이터를 View에 반영한다.
- Controller 뿐만 아니라 View도 Model이 가지고 있는 데이터를 접근할 수 있다.
Action -> Controller -> Model <=> View
- 하지만, 이 경우에서 Model과 View가 굉장히 많아진다면 골치 아파진다. 따라서 Flux라는 디자인패턴이 만들어졌다.
- 같은 상황에서, 어떠한 Action이 입력되었을 때 Dispatcher가 Store의 데이터를 업데이트하고, 이렇게 변경된 데이터를 View에 리렌더링하게 된다.
- 또한, View에서 Dispacther로 Action을 보낼 수도 있다.
Action -> Dispatcher -> Store -> View -> Dispatcher
- Dispatcher는 여러 Action이 들어와도 하나씩 Action을 처리 한 뒤 작업이 중첩되지 않도록 한다.
📌Redux
- Redux는 위에서 언급한 Flux 디자인 패턴을 쉽게 사용할 수 있게 하는 라이브러리이다.
- Store에서는 한 어플리케이션에서의 교류할 모든 데이터를 담고 있고 컴포넌트들 끼리 데이터를 교류하는 것이 아닌 중간자인 Store을 통해서 데이터를 주고받게 된다.
- View 혹은 특정 Action에서 Store가 가지고 있는 데이터를 업데이트하기 위해 Dispatcher를 사용한다.
- 컴포넌트에서는 특정 데이터를 주시하고 있다가 그 데이터가 변경된다면 바로 리렌더링 하게 된다. 이것을 subscribe라고 한다. (react의 sideEffect와 같은 느낌)
📌Redux의 3가지 원칙
- 1) Redux는 어플리케이션의 state를 위해 단 한개의
Store
를 사용한다.
(Store
의 구조는 개발자가 정하기 마련인데, 보통은 JS의 객체처럼 중첩된 구조로 이루어져있다. { {}{}{}, {} } 이런 식)
- 2)
State
는 읽기 전용이다.
(어플리케이션에서 state를 직접 변경할 수 없고, 변경하려고 하면 action이 dispatch되더야 한다. 여기서 action은 어떤 변화가 일어나야 할 지 알려주는 객체)
- 3) 변화는 순수 함수로 만들어져야 한다.
(두번째 원칙에서 말한것처럼, 직접 변경하는것은 허용하지 않는다. 그 대신에 action을 dispatch하여 상태값을 변경한다고 했는데 이 과정에서 받아온 action 객체를 처리하는 함수를 Reducer라고 부른다. Reducer는 순수 함수
로만 작성 되어야 한다.)
📌참고
참고한 사이트