FLUX 소개

오늘은 FLUX에 대해서 소개해 드리고자 합니다.

FLUX는 페이스북에서 React.js 와 함께 나온 라이브러리로 어플리케이션 내에 데이터를 취급하기 위한 패턴입니다.

단방향 데이터 흐름을 갖고 기존 MVC 모델의 한계를 극복하고자 만들어졌습니다.

그럼 FLUX의 배경부터 알아볼까요?

1.  FLUX의 배경은 MVC 패턴의 한계를 극복하고자 나왔다.

MVC 모델은 서버를 다룰 줄 아는 사람에게는 가장 유명한 패턴이라고 알고 있을 것입니다.

하지만 MVC 모델은 비동기적 구현이기에 발생하는 문제가 있습니다.

Model에서는 데이터와 관련된 내용들을 관리하고 Controller는 Model과 View 사이에서 중간자 역할을 하며

일 처리를 하게 됩니다.

View는 발표자 역할로 사용자들에게 데이터를 시각화 하는 역할을 합니다.

하지만 여기서 A 라는 개발자가 작업 간에 데이터를 변경한 상황이 생겼습니다. 

그러면 Model 내의 데이터가 변경되면서 여러 Controller를 거쳐 해당 Model 내의 데이터를 사용하는
View들에게 변경사항을 모두 공지해줘야 합니다.

하지만 비동기적 시스템이기 때문에 작업 진행 간에 변경된 것이기에 다른 뷰들에서는 해당 내용이 refresh 되지 않아서 

종종 변경되지 않는 경우도 발생합니다.

대표적으로 페이스북 메세지를 보면 나는 분명 페이스북 메세지 온 것을 확인을 하였는데 , 메세지 알림에는 읽지 않은
메세지가 있다고 표시가 되기도 하는 등의 문제가 있습니다.

구조도를 간략하게 보면 다음과 같습니다.

변경 사항을 데이터가 변경되었다면 컨트롤러가 모델에게도 수정해주고 해당 내용을 보여주는 View 단에서도 말을 해주게 되는데, View에서 변경된 사항을 다시 모델에 적용하고 모델에서는 또 변경한 내용을 View에 전송하고 이러한 복잡한 구조가 지속적으로 발생하게 된다.

이렇게 되면 어떤 뷰에선 아직 적용이 안된 경우도 발생하게 되는데 이러한 부분이 MVC 모델의 단점이자 비동기적 업데이트의 문제라 볼 수 있다.

이러한 점을 해결하고자 FLUX가 나오게 되었는데, 이는 단방향 데이터 흐름으로 시스템 별로 역할을 나누어 작업하는 구조이다.

동기적 흐름이기에 작업 간에도 하나의 일이 진행하는 동안은 다른 곳은 잠시 기다리도록 명령을 하고,
해당 일이 마무리 될 경우 다음 일을 할 수 있도록 진행하여 중간에 빠지는 경우가 없어지게 된다.

2. FLUX 소개 

Flux 는 앞서 설명하였듯 페이스북에서 React.js 라이브러리와 같이 만든 것으로 동기적 시스템 구조를 가지고 있다.

단방향 데이터 흐름으로 딱 이 구조로만 진행되는데, 동기적으로 진행된다는 점 다시 한 번 강조하고 싶다.

그럼 FLUX의 요소들에 대해서 알아보자

3. FLUX 요소 & 시스템 플로우

1.  액션 생성자

-  모든 변경사항과 사용자와의 상호작용이 거쳐가야 하는 액션의 생성을 담당

-  언제든 Application 상태를 변경하거나 View를 업데이트 하고 싶다면 액션을 생성해야 함

-  어떠한 것을 업데이트 할 지 정보를 주면 Action으로 바꿔서 Dispatcher에게 전달

-  타입과 페이로드를 포함한 액션을 생성 

2.   디스패쳐 (Dispatcher)

- Callback이 등록된 곳

- 전화 교환대에서 교환원 역할을 한다. 

- 액션을 보낼 필요가 있는 스토어들을 모두 가지고 있다. (연결망)

- 액션 생성자로부터 액션이 넘어오면 해당 액션이 적용될 스토어들에게 모두 전달한다.

- 스토어에 액션을 보내고 해당 내용이 처리가 될 때 까지 대기한다 ( waitFor() 함수 적용) --> 우선권이 있는 Action을 먼저 처리한다.  

- Action Type과는 무관하게 등록된 모든 스토어에 Action을 보낸다. ( Store는 구독하지 않아도 Action을 우선 받고 이를 처리 할 지 말지 결정한다.

3.   스토어 (Store)

- Application 내의 모든 상태와 관련 로직을 가지고 있다.

- Application 상태 변경은 모두 스토어에서 이뤄지며, 상태 변경을 위한 요청은 스토어에 직접 보낼 수 없다. (디스패처를 거쳐야함)

- 설정자가 존재하지 않기 때문에 상태 변경을 위해서는 반드시 모든 정해진 절차를 따라야 한다.
(액션 생성자 -> 액션 -> 디스패처 -> 스토어)

- 스토어가 디스패처에 등록되어 있다면, 모든 액션을 받게 될 것이고 스토어 내부에서는 보통 switch statement를 사용해서

처리할 액션과 무시할 액션을 결정하게 된다.

- 처리할 액션이라면 주어진 액션에 따라서 무엇을 할 지 결정하고 상태를 변경하게 된다. 

4.  뷰 (View)

- 변경된 사항을 사용자들이 알아볼 수 있게 랜더링하여 보여주는 부분이다.

- 주로 html을 통해서 사용자에게 전달되며 컨트롤러 뷰의 명령을 받아 Re-Rendering한다.

5.  컨트롤러 뷰 (Controller View)

- 스토어(Store)와 뷰(View) 사이에서 중간 매개자 역할을 하고 있으며 둘 사이에서 상태를 관리한다.

- 스토어에게 최신 상태를 계속해서 물어보면서 변경사항을 체크한다.

- 스토어가 기존 상태에서 변경된 상태를 전달해주면 이를 자기 아래에 존재하는 뷰(View) 들에게 모두 전달한다.

- 컨트롤러 뷰의 명령을 받은 뷰들은 re-rendering 작업을 통해 변경된 사항을 적용하여 사용자에게 보여주도록 한다.

[ 시스템 플로우 ] 

1.  스토어는 디스패처에 액션이 들어오면 알려달라고 한다.

2.  컨트롤러 뷰는 스토어에게 최신 상태를 묻는다.

3.  스토어가 컨트롤러 뷰에게 상태를 주면 Rendering 하기 위해서 컨트롤러 뷰는 자신의 모든 자식 뷰들에게 상태를 넘겨준다.

4.  컨트롤러 뷰는 스토어에게 상태가 바뀔 때 알려 달라고 한다.

5.  연락을 받은 컨트롤러 뷰들은 스토어들에게 변경된 상태를 요청한다.

6.  스토어가 새로운 상태를 넘겨주면 , 컨트롤러 뷰는 자신 아ㅐㄹ의 뷰들에게 새로운 상태에 맞게 Re-Rendering 하라고 명령한다.

http://bestalign.github.io/2015/10/06/cartoon-guide-to-flux/ 

해당 내용을 자세히 표시한 부분으로 만화로 표현 되어 있어서 보기 편할 것입니다. 

참조하시면 좋을 것 같습니다 !