2015년 글이네.
flux는 웹개발에서 가장 인기있으면서도 가장 이해안되는 토픽.
문제점
flux가 해결할수 있는 기본 문제가 있어.
flux는 패턴이야.
애플리케이션에서 데이터를 취급하기 위한 패턴.
flux와 react는 페북이 가진 문제점을 해결하기 위해 개발되었고, 페북에서 함께 커왔어.
보통 함께 사용하지만, 하나씩 사용할 수도 있어.
페북이 가진 문제점 대표주자는 알림(notification)버그.
페북에 로그인 했을때 , 화면위의 메시지 아이콘에 알림이 떠있지만, 클릭해서 들어가보면 아무 메시지도 없던 적던 적이 있었을거야. 알림은 사라지는데, 몇분뒤 다시 알림이 나타나고 아무 메시지 없는 사이클이 반복....
이 사이클은 단순히 사용자 뿐이 아니라 페북 팀에서도 있었어.
버그를 고쳐서 괜찮아지는듯 하더니 업데이트를 하다보면 곧 다시 나타나는 사이클이 반복....
페북은 땜빵 해결이 아닌, 시스템을 더욱 예측가능하게 만들어서 근본 해결을 찾아 ㄱㄱㄱ
근본적 문제점? 데이터가 애플리케이션을 흐르는 방법에 있..
페북이 찾은 근본적 문제점은 <데이터가 애플리케이션을 흐르는 방법>에 있었다.
(note : 이것은 페북이 공유한 단순화된 문서로부터 모은 것임.. 실제 아키텍처는 이것과는 아주 다를 것임)
이전에는 데이터를 가지고 있는 모델이 렌더링을 하기 위해 <뷰 레이어>로 데이터를 보냈을 것.
사용자와의 상호작용이 뷰를 통해 일어났기 때문에, 사용자의 입력에 따라 뷰가 가끔씩 모델을 업데이트할 필요가 있었음.. 그리고 [의존성(dependency) 때문에 ] 모델이 다른 모델을 업데이트해야할 때도 있었고.....
그 외에도, 가끔씩 이런 것들 때문에 산사태처럼 아주 많은 다른 변경을 초래하기도 했어... 이건 마치 아주 긴장감 넘치는 Pong 게임같아....공이 어딜로 날라갈지 알기 매우 어렵...(화면 밖으로 가버릴지도..)
또한 이런 변경들은 비동기적으로 생길수도 있었고, 하나의 변경이 다수의 변경들을 일으킬수도 있었고...
(Pong 게임에 공 한자루를 한꺼번에 던져 넣는다고 상상해봐...화면 모든 곳에 공이 마구 뒤섞여서 날라다니겠...)
뷰가 모델을 업데이트 하고, 모델이 다른 모델을 업데이트 한다. 점점 아주 긴장감 넘치는 Pong 게임처럼 보이기 시작함....
해결책 : 단방향 데이터 흐름(unidirectional data flow)
그래서!!! 페북은 다른 종류의 아키텍처를 시도 ㄱㄱ(그 아키텍처가 FLUX..). 이 구조에서 데이터는 단방향으로만 흐르고, 새 데이터를 넣으면 처음부터 흐름이 다시 시작되고...
flux를 이해한다면, 위의 다이어그램은 이해가 쉬울거야.flux는 시스템을 잘게 나누어 함께 일하는 여러 캐릭터로 생각해봐... 이제 내가 머릿속의 이 캐릭터들을 소개해보지!!!!
캐릭터를 만나보자. 어떻게 같이 상호작용할까??
1번 액션생성자(the action creator) : 메시지를 포맷에 맞게 변환시켜줌
첫번째 캐릭터. 모든 변경사항과 사용자와의 상호작용이 거쳐가야 하는 액션생성을 담당.
언제든 앱의 상태변경이나 뷰업데이트 하려면 액션을 생성해야만 한다.
무슨 메시지를 보낼지 알려주면, 액션생성자는 나머지 시스템이 이해할 수 있는 포맷으로 바꿔줘... (전신기사가 알파벳을 기계들이 처리할 수 있는 모스부호로 바꾸는 것처럼)
액션생성자는 타입(type)과 페이로드(payload)를 포함한 액션을 생성해. 타입은 시스템에 정의된 액션들(일반적으로 상수들) 중의 하나야. 액션의 예로는 MASSAGE_CREATE, MESSAGE_READ 같은 것이 있음..
모든 가능한 액션들을 아는 시스템을 가짐으로써 부차적으로 갖는 멋진 효과가 있어. 새로운 개발자가 플젝에 들어와서 행동생성자 파일을 열면 시스템에서 제공하는 API전체(모든 가능한 상태변경)을 바로 확인가능...
일단 액션생성자가 액션메시지를 생성한 뒤에 디스패쳐(dispatcher)로 넘겨줌...
2번 디스패쳐: 교환원 업무.. 모든 스토어를 위한 콜백을 가지고 있음.
디스패쳐는 기본적으로 콜백이 등록되어 있는 곳.
전화교환대에서 교환원이 일하는 것처럼...(전화교환대에서는 등록된 모든 전화들과의 연결이 가능함..)
디스패쳐는 액션을 보낼 필요가 있는 모든 store(스토어)를 가지고 있고, 액션 생성자로부터 액션이 넘어오면 여러 스토어에 액션을 보냄..
이 처리는 동기적으로 실행되어서 위쪽에서 이야기했던 다수의 공으로 플레이하는 Pong 게임같은 경우를 처리하는데 도움을 줌.. 만약 스토어들 사이에 의존성(dependency)이 있어서 하나를 다른것보다 먼저 업데이트를 해야한다면, waitFor()를 사용해서 디스패쳐가 적절히 처리하도록 할 수 있음.
flux의 디스패쳐는 다른 등장인물과 좀 다른점이 있는데,,, 바로 액션타입과는 관계없이 등록된 모든 스토어로 보내진다는 점.. 뭔말이냐면, 스토어가 특정 액션만 구독(subscribe)하지 않고 모든 액션을 일단 받은뒤 처리할지 말지를 결정한다는 뜻..
3번 스토어 : 중앙관료와 같음.. 모든것 관리함. 모든 변경사항은 이곳을 지나가야 함
스토어는 앱 내의 모든 상태와 관련 로직 가짐.
모든 상태변경은 반드시 스토어에 의해서 결정되어야만 해. 상태변경을 위한 요청을 스토어에 직접 보낼순 없어.
스토어에는 설정자(setter)가 없어. 그러니 상태변경을 요청하려면 절차를 따르면 되는데,, 무조건 액션생성자/ 디스패쳐 파이프라인을 거쳐서 액션을 보내야 해..
만약 스토어가 디스패쳐에 등록되어 있다면, 모든 액션을 받게 될 거야. 스토어의 내부에서는 보통 switch statement를 사용해서 처리할 액션과 무시할 액션을 결정하게 돼.. 만약 처리가 필요한 액션이라면, 주어진 액션에 따라 뭘 할지 결정하고 상태를 변경하게 되지..
일단 스토어에 상태 변경을 완료하고 나면, 변경 이벤트(change event)를 내보낸다. 이 이벤트는 컨트롤러 뷰에 상태가 변경했다는 것을 알려주게 된다.
4번 컨트롤러뷰,뷰 :컨트롤러뷰는 중간관리자..뷰는 발표자!!! 뷰는 상태를 가져오고 유저에게 보여주고 입력받을 화면을 렌더링하는 역할
컨트롤러뷰는 스토어로부터 알림을 받고 자기 아래의 뷰로 전달해주는 중간관리자임.
뷰는 가지고 있는 데이터를 사용자에게 보여줌..
뷰는 발표자와 같다. 앱 내부에 대해서는 아는 건 없지만, 받은 데이터를 처리해서 사람들이 이해할 수 있는 포맷(HMTL)로 어떻게 바꾸는지를 알고 있어.
컨트롤러뷰는 스토어와 뷰 사이의 중간관리자 역할. 상태가 변경되면 스토어가 그 사실을 컨트롤러 뷰에게 알려주고, 컨트롤러뷰는 자기 아래에 있는 모든 뷰에게 새로운 상태를 넘겨준다.
어떻게 함께 동작하지??
1. 준비 (the setup)
먼저 앱이 초기화할때 딱 한번 준비과정을 가진다.
1. 스토어는 디스패쳐에 액션이 들어오면 알려달라고 말해둬...
2. 컨트롤러뷰는 스토어에게 최신 상태를 물음
3. 스토어가 컨트롤러뷰에게 상태를 주면, 렌더링하기 위해 모든 자식 뷰에게 상태를 넘겨줌..
4. 컨트롤러 뷰는 스토어에게 상태가 바뀔때 알려달라고 다시 부탁한다.
2. 데이터흐름(the data flow)
준비과정이 끝나면 앱은 유저 입력을 위한 준비완료!!
사용자 입력으로 인한 액션이 생겼을 경우를 보자.
사용자 입력으로부터 데이터 흐름을 만들것이당..
1. 뷰는 액션생성자에게 액션을 준비하라고 말해.
2. 액션 생성자는 액션을 포맷에 맞게 만들어서 디스패쳐에 넘겨줘.
3.디스패쳐는 들어온 액션의 순서에 따라 알맞은 스토어로 보내. 각 스토어는 모든 액션을 받게 되지만 필요한 액션만을 골라서 상태를 필요에 맞게 변경해..
4. 상태변경이 완료되면 스토어는 자신을 구독하고 있는 컨트롤러 뷰에게 그 사실을 알려..
5. 연락을 받은 컨트롤러 뷰들은 스토어에게 변경된 상태를 요청해..
6. 스토어가 새로운 상태를 넘겨주면, 컨트롤러뷰는 자기 아래의 모든 뷰에게 새 상태에 맞게 렌더링하라고 알리지.
참고자료 : http://bestalign.github.io/2015/10/06/cartoon-guide-to-flux/
