Flux 패턴

MVC(Model-View-Controller) 아키텍처

컨트롤러: 모델의 데이터를 조회하거나 업데이트하는 역할
모델의 변화는 뷰에 반영된다.
사용자는 뷰를 통해 입력하여 모델에 변화를 줄 수 있다.
그리고 의존성 때문에 모델이 다른 모델을 업데이트 해야할 때도 있다.
이와 같이 MVC 아키텍처를 사용했을 때
변경은 비동기적으로 생길 수도 있었고, 하나의 변경이 다수의 변경을 일으킬 수 있었다.
이런 의존성과 순차적 업데이트는 종종 데이터의 흐름을 꼬이게 하여 예상치 못한 결과를 불러일으키고 데이터의 흐름을 디버그하기 어렵게 만든다.

디버그(Debug)
개발 단계 중에 발생하는 시스템의 논리적 오류나 비정상적 연산을 찾아내고 수정하는 작업 과정

이를 비롯한 여러 문제 때문에 페이스북 개발팀이 새로운 아키텍처를 만들었는데 이것이 Flux 패턴이다.

단방향 데이터 흐름(unidirectional data flow)

Flux 구조에서는 데이터가 단방향으로만 흐르게 하고, 새로운 데이터를 넣으면 처음부터 흐름이 다시 시작된다.

Action -> Dispatch -> Store -> View -> Action -> Ditpatch ...

액션 생성자 (Action creator)

모든 변경사항과 사용자와의 상호작용이 거쳐가야 하는 액션의 생성을 담당한다.
애플리케이션의 상태를 변경하거나 뷰를 업데이트 하고 싶다면 액션을 생성해야 한다.
액션 생성자는 type과 payload를 포함한 액션을 생선한다.

• type: 시스템에 정의된 액션들 중의 하나 (일반적으로 상수들)
  액션 메시지를 생성한 뒤에는 dispatcher로 넘겨준다.

디스패쳐 (dispatcher)

디스패쳐는 기본적으로 콜백이 등록되어 있는 곳이다.
액션을 보낼 필요가 있는 모든 store를 가지고 있고 액션 생성자로부터 액션이 넘어오면 여러 스토어에 액션을 보낸다.
동기적으로 처리 되기 때문에 하나를 다른 것보다 먼저 업데이트 해야한다면, waitFor()을 사용하여 디스패쳐가 적절히 처리하도록 할 수 있다.
또한 액션 타입과 관계없이 등록된 모든 스토어로 액션을 보내기 때문에 스토어가 특정 액션만 구독하지 않고 모든 액션을 받고 처리를 결정할 수 있다.

스토어 (store)

스토어는 애플리케이션 내의 모든 상태와 그와 관련된 로직을 가지고 있다.
모든 상태 변경은 반드시 스토어에 의해 결정되어야 하며, 상태변경을 위한 요청을 스토어에 직접 보낼 수 없다. (상태 변경을 요청하기 위해선 액션 생성자/디스패쳐 파이프라인을 거쳐서 액션을 보내야 한다.)
스토어의 내부에서는 보통 switch statement를 사용해서 받은 모든 액션 중 처리할 액션과 무시할 액션을 결정하고 상태를 변경하게 된다.
상태 변경 완료 후 컨트롤러 뷰에 상태가 변경했다는 것을 알려준다.

컨트롤러 뷰와 뷰

스토어가 상태 변경을 알려주면 컨트롤 뷰가 스토어에게 변경된 상태를 요청한다.
컨트롤 뷰는 자신 아래에 있는 모든 뷰에 새로운 상태를 넘겨준다.
이를 처리해서 사람들이 이해할 수 있는 포맷으로 변환한다.

위와 같은 단방향 데이터 흐름을 가지고 있는 Flux의 구현체로 널리 사용되고 있는 것 중 하나가 "Redux"이다.