Flux 패턴

MVC 패턴을 보완하기 위해서, FaceBook에서 만든 아키텍처를 소개해봅시다.

 

간단하게 단방향 데이터이고, Action이 발생하면 Dispatcher에 의해 Store에 전달되고, Store가 변경되면, View가 변경되는 패턴입니다.

 

조금 더 자세하고, 쉽게 알아보도록 합시다 !

 

해당 글은 아래 글을 참조하여 작성한 글입니다.

 

ui.toast.com/weekly-pick/ko_20151027

Flux 카툰가이드 | TOAST UI :: Make Your Web Delicious!

---

문제

Flux가 해결하려는 문제가 뭐길래 탄생했을까요? 여러가지 문제를 해결하기 위해서 탄생하긴 했지만, 가장 잘 알려진 문제는 노티피케이션 버그라고 합니다.

 

Facebook 메시지 아이콘에 노티피케이션 카운트를 볼 수 있는데, 클릭해도 메시지가 없는 경우가 있습니다. 그리고 얼마 지나지 않아 또 노티피케이션이 나타나게 됩니다. 즉 버그가 발생했죠.

한무알림

개발자한테도 이런 문제가 발생했고, 핫픽스를 해도 다시 버그가 발생하고, 이슈 해결하고 버그 발생하고 이런 사이클이 반복 됐습니다.

 

그래서 근본적인 원인을 찾으려고 나섰죠.

 

그들이 찾은 잠재적인 문제는 앱안에서 데이터가 흐르는 방법 때문이었답니다.

 

뷰에 데이터를 전달하여 그리도록 하는 모델들이 있는데, 요게 연쇄적이고 비동기로 데이터가 오가면서 한가지의 변화가 여러개의 다른 변화를 발생시키는 문제가 발생된 것이었습니다. 게다가 이런 데이터 플로우는 디버깅하기도 힘들죠.

 

으악

해당 문제를 해결하기 위해서 단방향 데이터 흐름을 시도했습니다.

 

데이터를 한 방향으로만 흐르게 해서 만약 새로운 데이터를 추가한다면 제일 처음부터 다시 흘러가게 하는 것이며, 이런 아키텍처를 플럭스라고 이름 지었습니다.

보다 간편해졌다.

이제 각 역할을 한 번 알아보도록 합시다.

ACTION

첫번째는 액션입니다. 모든 변화와 인터렉션이 커쳐가는 통로의 시작이 되는 액션을 만드는 일을 합니다. 앱의 스테이트를 변경하거나 뷰를 다르게 그리려면 액션을 만들어야 합니다.

액션을 만들자

음... 아직까지 이해가 힘들다면, ACTION은 어떤 메시지를 보내야 하는지를 알게하면 다른 시스템이 이해할 수 있는 방법으로 형식을 맞춰주는 것입니다.

 

ACTION의 경우 타입과 전달될 데이터로 액션을 만드는데, 이렇게 가능한 모든 액션을 따로 모아서 관리하는 것은 시스템이 제공하는 모든 API를 한 번에 볼 수 있어서 좋습니다. 액션 메시지가 만들어지면 액션을 디스패처에게 전달을 합니다

디스패처

디스패처는 간단하게 콜백 등록기 역할을 합니다. 액션을 전달돼야 하는 스토어의 목록을 가지고 있으며 액션을 스토어에게 전달하는 역할을 합니다.

해당 내용 접수해서 검토 중입니다. ^_^

Flux의 디스패처는 다른 많은 아키텍처에서 볼 수 있는 디스패처와는 다르게, 액션이 모두 등록된 스토어들에게 액션 타입에 상관없이 전달 됩니다. 모든 종류의 액션을 감지 하고 있다가 관심을 갖는 액션에만 반응을 합니다.

스토어

스토어의 경우엔 모든 스테이트를 가지고 있고 실시간으로 로직을 스토어 안에서 변경합니다.

주식 창을 바라보는 역할이랄까?

독단적인 관리자로서 모든 스테이트는 스토어에 의해 독자적으로 만들어집니다. 직접 스테이트를 변경할 수도 없습니다. ACTION / DISPATCHER / STORE 플로우를 통해서 스테이트를 변경해야합니다.

 

STORE가 STATE에 변화를 주게되면 change event가 발생하게 되고 Controller View에게 스테이트가 변경되었다고 알려줍니다.

 

컨트롤러뷰와 뷰

뷰들은 스테이트를 전달 받아 화면에 그려 유저들에게 보여주고 유저의 입력을 받는 역할을 합니다.

보고

애플리케이션에서 벌어지는 일들은 상관없이 다뤄야할 데이터에만 관심이 있으며 이를 보여주는 방법을 알고 있습니다. 컨트롤러 뷰는 스토어와 뷰 사이의 중간 관리자 역할을 하고, 스테이트가 변경되면 스토어에게 알려주고 컨트롤러 뷰는 새로운 스테이트를 수집해 업데이트된 스테이트를 관련된 뷰들에게 전달하는 역할을 합니다.

초기화

단방향이라고 해도 처음에 실행될 때에는 보다 복잡한 방향이 있기에 짚고 넘어가야할거 같습니다.

 

초기화 시에는 아래와 같은 작업을 진행합니다.

 

야 망 좀 보고 있어라

1. 디스패처에게 액션이 들어올 때마다 알려주도록 시킵니다.

2. 그 와중에 컨트롤러뷰가 스토어에게 최근 스테이트를 요청하고, 스토어가 컨트롤러뷰에게 스테이트를 전달하면 컨트롤러 뷰는 뷰에게 이를 전달하여 화면에 그리도록 합니다.

물건 주시면 그리게 시킬게요

3. 컨트롤러뷰는 스토어에게 스테이트 변경되면 알려달라고 요청합니다.

아 그리고 물건 들어오면 바로바로 말해줘야합니다.

여기까지 초기화를 봤으니, 이제 초기화 후 데이터 흐름을 봅시다.

플로우

초기화가 끝나면 어플리케이션은 입력을 받을 준비가 끝났고, 유저는 액션을 발생 시키면서 데이터 플로우가 시작 됩니다.

 

1. 뷰가 액션에게 액션 들어왔다고 알립니다.

주문이요~

2. 액션에서 디스패처로 전달한다. (이 때 액션을 만들어서 전달한다)

이거 들고 가서 반영하십쇼.

3. 디스패처는 스토어에게 순서에 맞춰 액션을 전달하고, 모든 액션을 전달 받은 스토어는 스테이트를 알맞게 바꿉니다.

이렇게 고쳐라는데요?

4. 이제 스테이트 반영이 됐으니, 알려주면서 뷰를 수정합시다.

새 물건 들어왔다

야 새 물건 들어왔대, 이거 그려

---

이상 Flux 패턴이었습니다. ^_^