Flux
애플리케이션에서 데이터를 취급하기 위한 패턴
Flux는 Facebook이 가지고 있었던 특정한 문제점들을 해결하기 위해서 개발되었다.
근본적인 문제점
- Facebook이 찾은 근본적인 문제점은 데이터가 애플리케이션을 흐르는 방법에 있었다.
- 모델(model)이 뷰 레이어로 데이터를 보낸다.
(실제 아키텍처는 그림과는 아주 다르다.)
사용자와의 상호작용이 뷰를 통해서 일어났기 때문에 사용자의 입력에 따라 뷰가 가끔씩 업데이트해야할 필요가 있었다. 그리고 의존성 때문에 모델이 다른 모델을 업데이트해야할 때도 있었다.
그 외에도, 가끔씩 이런 것들 때문에 아주 많은 다른 변경을 초래 할 수도 있다.
(뷰가 모델을 업데이트하고, 모델이 다른 모델을 업데이트한다. 그림을 봐도 하나의 공을 던져놓고 이동하면 복잡하고 정리가 안되는 것과 같은 모습을 보인다. )
해결책
이러한 문제점에 Facebook은 다른 종류의 아키텍처를 시도하였다. 단방향 데이터 흐름으로 데이터는 단방향으로만 흐르고 새로운 데이터를 넣으면 처음부터 흐름이 다시 시작된다. 이 아키텍처를 Flux라고 부른다
- 그림에서 보여지는 다이어그램을 쉽게 역할이 있는 캐릭터로 보자!
액션 생성자
- 모든 변경사항과 사용자와의 상호작용이 거처가야하는 액션의 생성을 담당, 언제든 애플리케이션의 상태를 변경하거나 뷰를 업데이트하고 싶다면 액션을 생성해야만 한다.
- 액션 생성자가 하는 일은 전보기사와 같다 무슨 메시지를 보낼지 알려주면 액션 생성자는 나머지 시스템이 이해할 수 있는 포맷으로 바꿔준다.
- 액션 생성자는 타입과페이로드를 포함한 액션을 생성한다.
- 액션생성자가 액션 메시지를 생성한 뒤에는 디스패쳐로 넘겨준다.
디스패쳐
- 디스패쳐는 기본적으로 콜백이 등록되어있는 곳이다. 전화 교환대에서 교환원이 일하는 것과 같다. (전화 교환대에서는 등록된 모든 전화들과의 연결이 가능하다.) 디스패쳐는 액션을 보낼 필요가 있는 모든 스토어를 가지고 있고, 액션 생성자로부터 액션이 넘어오면 여러 스토어에 액션을 보낸다.
- 디스패쳐는 전화교환원 같다. 모든 스토어를 위한 콜백을 가지고 있다.
- Flux의 디스패처는 다른 아키텍처들과는 다른 점이 있다. 액션 타입과는 관계없이 등록된 모든 스토어로 보내진다는 점이다. 스토어가 특정 액션만 구독하지 않고 모든 액션을 일단 받은 뒤 처리할지 말지를 결정한다.
스토어
- 스토어는 애플리케이션 내에 모든 상태와 그와 관련된 로직을 가지고 있다.
- 스토어는 마치 모든 것을 관리하는 관료와 같다. 모든 변경사항은 이곳을 지나가야 한다.
- 스토어가 디스패쳐에 등록되어 있다면 모든 액션을 받게 될 것이다. 스토어의 내부에서는 swich statement를 사용해서 처리할 액션과 무시할 액션을 결정하게 된다. 만약 처리가 필요한 액션이라면, 주어진 액션에 따라 무엇을 할 지 결정하고 상태를 변경하게 된다. 일단 스토어에 상태 변경을 완료하고 나면, 변경 이벤트를 내보낸다. 이 이벤트는 컨트롤러 뷰에 상태가 변경했다는 것을 알려준다!
컨트롤러 뷰 와 뷰
- 뷰 : 상태를 가져오고 유저에게 보여주며 입력받을 화면을 렌더링하는 역할
- 컨트롤러 뷰 : 스토어로 부터 알림을 받고 자신 아래의 뷰로 전달해주는 중간 관리자와 같다. 뷰는 가지고 있는 데이터를 사용자에게 보여준다.
동작 준비
- 스토어는 디스패쳐에 액션이 들어오면 알려달라고 말해둔다.
- 컨트롤러 뷰는 스토어에게 최신 상태를 묻는다.
- 스토어가 컨트롤러 뷰에게 상태를 주면 렌더링하기 위해 모든 자식 뷰에게 상태를 넘겨준다.
- 컨트롤러 뷰는 스토어에게 상태가 바뀔 때 알려달라고 다시 부탁한다.
데이터 흐름
준비과정이 끝나면 애플리케이션은 유저 입력을 위한 준비가 완료된다. 사용자의 입력으로 인한 액션이 생겼을 경우를 보자.
사용자 입력으로 부터 데이터 흐름을 만들고
1. 뷰는 액션 생성자에게 액션을 준비하라고 말한다.
2. 액션 생성자는 액션을 포맷에 맞게 만들어서 디스패쳐에 넘겨준다.
3. 디스패쳐는 들어온 액션의 순서에 따라 알맞은 스토어로 보낸다. 각 스토어는 모든 액션을 받게 되지만 필요한 액션만을 골라서 상태를 필요에 맞게 변경한다.
4. 상태 변경이 완료되면 스토어는 자신을 구독하고 있는 컨트롤러 뷰에게 그 사실을 알린다.
5. 연락을 받은 컨트롤러 뷰들은 스토어에게 변경된 상태를 요청
6. 스토어가 새로운 상태를 넘겨주면, 컨트롤러 뷰는 자신 아래의 모든 뷰에게 새로운 상태에 맞게 렌더링하라고 알린다.
출처 : http://bestalign.github.io/2015/10/06/cartoon-guide-to-flux/
