티스토리 FLUX javascript js facebook
Flux
Flux는 페이스북의 클라이언트 사이드 웹 애플리케이션 구축을 위한 아키텍쳐다. 이것은 한 방향으로의 데이터 흐름을 이용하여 React의 composable view 컴포넌트를 보완한다. 이것은 좀 더 큰 컨셉의 패턴이지, 공식적은 프레임워크는 아니다. 그리고 당신은 Flux를 새로운 코드 없이 바로 시작할 수 있다.
개괄
Flux 애플리케이션들은 3가지 주요한 파트로 구성된다. Dispatcher, Store, 그리고 View들(React 컴포넌트)이 그것이다. 이것들과 Model-View-Controller를 헷갈리지 말아야 한다. Controller는 Flux애플리케이션에도 존재하지만, Controller-View의 형태로만 존재한다. View들은 데이터를 Store에서 받거나, 그들의 자식 Store에게 데이터를 패스하기 위해 최상위 계급에 자주 위치한다. 게다가 Action Creator - Dispatcher의 헬퍼 메소드들 - 는 애플리케이션에서 가능한 모든 변화들을 묘사하기 위해 시멘틱한 API를 지원한다. Flux의 업데이트 사이클의 4가지 파트로서 이것들을 이해하면 상당히 편하다.
Flux는 MVC에서 양방햔 바인딩을 피한다. 유저가 React뷰와 인터렉션할 때, 뷰는 중심의 디스패처를 통하여 애플리케이션의 데이터와 비즈니스 로직 - 영향을 받은 모든 뷰들을 업데이트 하는 - 을 수행하는 다양한 스토어들에 로 Action을 전파한다.
이러한 작업들은 State 사이에서 어떻게 뷰들이 변할지 구체적으로 특정하지 않아도 스토어에게 업데이트들을 보낼 수 있도록 하는 특히 React의 Declarative 프로그래밍 스타일에서 유용하다.
우리는 파생된 데이터를 정확히 다루기 위해서 원래 시작했다. 예를들어 우리는 톡방들에서 아직 읽지 않은 것들의 숫자들을 읽지 않은 톡방이 하이라이트 되면서 톡방의 리스트와 함께 보여주길 바랐다. 한 톡방을 읽었다고 업데이트하면서, 동시에 읽지 않았다는 숫자를 동시에 업데이트 하는 것같은, 이런 일들은 MVC모델로는 다루기가 매우 힘들다. 의존적이고 폭포수처럼 전파되는 업데이트들은 MVC 아키텍쳐를 이용하는 큰 애플리케이션에서 자주 발생한다. 그리고 복잡한 데이터 흐름으로 예상치 못한 결과들을 초래한다.
제어권은 Store에게 역전된다. 스토어들은 업데이트를 받아들이고, 그들의 일관적인 방법으로 데이터를 업데이트 하게되는 외부적인 무언가에 의존하기보다, 그들을 적절하게 조정한다. 어떠한 외부 스토어들도 그 도메인을 위한 데이터들이 어떻게 관리되는지에 대해 전혀 이해하고 있지 않다. 이는 쓸데없는 걱정거리를 만들지 않는다. 스토어들은 어떤 다이렉트 Setter 메소드도 들고있지 않다. 예를 들어 setAsRead()같은. 그러나 대신 새로운 데이터를 그들 속의 세계로 가져오는 한가지 방법만이 존재한다. - 바로 callback이다. Dispatcher로 그들이 등록한.
스트럭쳐와 데이터 흐름
Flux의 데이터들은 한 방향으로만 흐른다.
단방향 데이터 흐름은 Flux 패턴의 중심이다. 그리고 위 다이어그램은 Flux 프로그래머에게 주요 맨탈 모델이어야 한다. 디스패처, 스토어, 뷰들은 명확한 인풋과 아웃풋이 있는 서로 독립적인 노드들이다. Action들은 간단한 오브젝트로, 새로운 데이터를 가지고 있고 어떤 타입의 프로퍼티인지에 대한 정보를 제공한다.
뷰들은 유저의 인터렉션들에 대한 반응과 관련된 새로운 Action을 생성할 것이다. 그리고 이러한 액션들은 시스템에 의해 전파된다.
모든 데이터는 중심 허브로서 Dispatcher를 통해 흐른다. Action은 Action creator 메소드 안에서 디스패처에게 제공된다. 그리고 더 자주는 뷰에서의 유저 인터렉션을 통해 대부분 생성될 것이다.
디스패처는 스토어들이 이미 dispatcher에게 등록했던, 모든 스토어들의 액션들을 스토어들에 전달하고 callback을 호출한다. 스토어 그들이 유지하는 스테이트들과 관련된 어떤 액션이든 등록된 컬벡 내에서 스토어들은 응답하게 된다. 스토어들은 그 후, 데이터 레이어의 변화를 Controller-Views들에게 알리기 위해 change 이벤트를 방출(emit)한다. Controller-View는 이러한 이벤트들을 리스닝하고 있다가 방출이 되면 이벤트 핸들러를 통해 스토어에서 데이터를 가져온다. 컨트롤 뷰는 그들 자신의 setState() 메소드를 스스로를 리렌더하고, 또 컴포넌트 트리의 후손들을 리렌더 하기위해 호출한다.
이 구조는 우리에게 한가지 방법으로 쉽게 애플리케이션을 추론할 수 있도록 한다. functional reactive programming, 혹은 더 구체적으로 data-flow programming 혹은 flow-based programming을 을 연상시키는 방법을 이용해서. 이 방법들에서는 애플리케이션의 데이터 플로우들은 한 뱡향으로 흐른다. 두 방향 바인딩은 없다.
애플리케이션 내의 특정 파트는 하나의 스토어에 의해 매우 decoupled된 채로 상태(state)가 유지된다. 동기적으로 업데이트가 디스패처에 의해 관리되면서, 스토어들의 의존성이 있는 곳에서는 엄격한 계급 체계을 유지한다.
우리는 두 방향의 데이터 바인딩이 한가지 오브젝트의 변화가 다른 오브젝트의 변화를 일으키는 캐스케이딩 업데이트를 발생시킨다는 것을 알았다. 그 뿐만 아니라 그 변화 또한 더 많은 업데이트들을 트리거 할 수 있다. 애플리케이션이 커지면서 이런 케스케이딩 업데이트들은 유저 인터렉션의 결과로서 무엇이 바뀌어 져야 하는지에 대한 결과물에 대한 예측하기 힘들게 한다. 업데이트가 하나의 라운드안에서 데이터를 변경할 때, 시스템은 전체로서 예측가능해진다.
다양한 Flux의 파트를 자세히 보자. 디스패처는 시작으로서 가장 적절한 선택이다.
하나의 Dispatcher
Flux 애플리케이션에서 모든 데이터 플로우를 관리하는 디스패처는 중앙 허브다. 기본적으로 디스패처는 스토어들의 안속의 callback들의 저장소(레지스트리)로 그 스스로는 어떠한 실질적 지능도 없다. 그것은 액션을 스토어로 분배하는 간단한 기계장치다. 각 스토어들은 dispatcher에 그들 스스로 뿐만 아니라 callback도 등록한다. Action creator가 디스패처에게 새로운 액션을 제공할 때, 애플리케이션 내 모든 스토어들은 저장소(레지스트리)안에있는 callbakc들을 통해 액션을 받는다.
애플리케이션의 성장에 따라, 디스패처는 좀 더 활성화된다. 이때 스토어들 사이에서 특정한 순서대로 등록된 callback을 호출해 주어 의존성을 관리하는데 사용될 수도 있다. 스토어는 선언적으로 기다릴 수 있다. 다른 스토어들이 업데이트를 완료하기까지. 그리고 나서 그들 스스로를 그에맞춰 업데이트한다.
페이스북이 프로덕션에서 사용하는 디스패처는 npm, Bower, or GitHub에서 이용할 수 있다.
스토어(Stores)
스토어는 애플리케이션의 스테이트와 로직을 가지고 있다. 그들의 역활은 뭔가 비슷한데, MVC에서의 모델이 그것이다. 그러나 그들은 다양한 오브젝트의 상태(state)를 관리한다. 그들은 ORM 모델이 하듯 하나의 단순한 레코드로 표현될 수 없다. Backbone의 콜렉션과도 마찬가지로 다르다. 간단히 ORM 스타일의 오브젝트를 관리하는 것 그 이상이다. 스토어는 특별한 도메인(책임영역)을 위한 애플리케이션의 상태(state)를 관리한다.
예를 들어보자. 페이스북의 Lookback Video Editor는 계속 재생시간의 위치와 재생 상태를 트래킹하는 TimeStore를 사용한다. 한편, 같은 애플리케이션의 ImageStore는 계속 이미지들의 컬렉션을 트래킹한다. 우리 TodoMVC Example에 있는 TodoStore도 비슷한데 todo 아이템의 컬렉션을 다룬다. 스토어는 2가지 특성을 보인다. 하나는 모델들의 컬렉션이고 또 다른 하나는 논리적인 도메인의 싱글톤 모델이다.
위에도 이야기했듯, 스토어는 그들 스스로를 디스패처에게 callback과 함께 직접 등록한다. 이 callback은 액션을 파래머터로 받는다. 스토어가 등록한 콜벡 안에서, 액션타입에 기반한 switch문은 액션을 번역하는데 사용될 뿐만 아니라 스토어 내부의 메소드들에게 적절한 훅(hook)을 제공하는데 사용된다. 이것은 액션이 디스패처를 통해 스토어의 상태 업데이트를 가능하도록 한다. 스토어가 업데이트 된 후, 그들은 스테이트가 바뀌었다는 이벤트를 내뿜는데, 이를 통해 뷰들은 새로운 상태를 질의할 수 있고, 그들 스스로를 업데이트 한다.
뷰(Views)와 Controller-Views
우리가 뷰레이어에서 필요로 하는 구성 가능한 종류의, 그리고 자유롭게 미리 랜더할 수 있는 뷰들을 React는 제공한다. 얽혀있는 뷰 계급의 최상단을 가까이에서 보면, 어떤 뷰가 의존하는 스토어가 브로드캐스트하는 이벤트들을 리스닝하는 특별한 뷰들이 존재한다. 우리는 이걸 컨트롤 뷰라고 부른다. 그들은 데이터를 스토어에서 가져오거나 혹은 그들의 후손들에게 데이터를 내려주는일을 위한 접착 코드를 제공한다. 우리는 이런 컨트롤 뷰들에게 중요한 섹션 하나를 할당해 주어야 할 것 같다.
이벤트를 스토어에서 받았을 때, 스토어의 public getter 메소드들로 필요한 새 데이터를 먼저 요청한다. 이후 자신의 setState()혹은 forceUpdate()메소드(그것의 render()메소드와 하부 자손들의 render() 메소드들을 실행하는)들을 호출한다.
우리는 자주 스토어의 전체 상태(state)를 뷰들의 체인이 있는 하부로 전달한다. 이것은 다른 후손들이 그들이 필요로 하는 것을 사용할 수 있도록 허락한다. 게다가 가장 최상위에서도 컨트롤러 비슷한 행동을 유지하기, 또 이렇게 우리의 자손 뷰들을 유지하기 위해, 가능한한 기능적으로 퓨어하게 모든 스토어의 상태를 싱글 오브젝트로 하부에 전달하는 것은 우리가 관리해야할 프로퍼티들의 수를 줄여주는 효과가 있다.
가끔, 우리는 안쪽(최상위가 아닌) 컨트롤 뷰를 컴포넌트를 간단히 유지하기 위해 가끔 추가할 필요를 느낀다. 이것은 특정 도메인의 섹션의 계층을 더 낫게 캡슐화 할 수 있게 해주기도 한다. 그러나 안쪽의 컨트롤러뷰는 하나의 데이터 흐름을 깰 수도 있다는 점을 알아야한다. 이런 컨트롤 뷰는 새로운 데이터 흐름을 위한 엔트리 포인트를 만들 수 있으며, 이는 잠재적인 충돌 가능성을 가지고 있다. 안쪽의 컨트롤 뷰를 만들 때는 간단한 컴포넌트의 이점과 복잡한 다수의 업데이트 사이에서 조율을 해야한다. 이러한 다수의 데이터 업데이트는 의도치 않은 영향을 만들 수 있는데, 다른 컨트롤뷰에 의해 계속적으로 호출되는 React의 렌더링 메소드의 getting에서 그렇다. 그리고 이건 잠재적으로 디버깅의 어려움을 증가시킬 수 있다.
액션(Actions)
우리가 스토어에게 분배(dispatch)를 트리거할 수 있도록, 그리고 데이터 페이로드 - 이것이 우리가 부르는 액션 - 를 포함 할 수 있게 디스패처는 한 메소드를 노출시킨다. 시멘틱한 헬퍼 메소드 안에, 엑션의 생성은 아마 래핑되어있을 것이다. 그것은 액션을 디스패처에게 보낸다. 예를들어, 우리는 To-do 아이템의 글자를 To-do List 애플리케이션에서 바꾸길 원할 수 있다. 우리는 TodoActions 모듈 안에 updateText(todoId, newText)같은 함수로 액션을 생성한다. 이 메소드들은 아마 우리의 뷰 이벤트 핸들러에 의해 호출될 것이다. 우리는 이것을 유저 인터렉션의 결과라 부를 수 있다. 이 액션 생성 메소드는 또한 액션에게 타입을 추가한다. 그래서 액션이 스토어에서 해셕될 때, 적절하게 응답할 수 있도록 한다. 우리의 예시에서는 이런 타입은 아마 TODO_UPDATE_TEXT같이 이름 붙여질 것이다.
액션은 아마 다른 장소들에서 올때도 있다, 서버같은 곳에서. 예를들어, 데이터를 초기화하는 동안 이런일이 일어난다. 또 마찬가지로 서버가 에러코드를 반환할때나 혹은 애플리케이션을 업데이트할때 같을때도 일어난다.
디스패처를 좀 더 보면,
아까 얘기했지만, 디스패처는 스토어들 사이의 디펜던시도 관리가 가능하다. 이런 기능은 디스패처 클래스의 waitFor() 메소드를 통해 가능하다. 우리는 지금 이런 메소드를 쓸 필요가 없다. 왜냐면 TodoMVC 애플리케이션이 굉장히 단순하니까. 그러나 이것은 크고 복잡한 애플리케이션에선 활성화될 것이다.
TodoStore의 등록된 콜벡 안에서 우리는 명시적으로 진행전에 다른 디펜던시들이 먼저 업데이트 되도록 기다릴 수 있다.
case 'TODO_CREATE':
Dispatcher.waitFor([
PrependedTextStore.dispatchToken,
YetAnotherStore.dispatchToken
]);
TodoStore.create(PrependedTextStore.getText() + ' ' + action.text);
break;
waitFor()은 한가지 argument만 받는다. 그 argument는 디스패처의 콜백 저장소(레지스트리) 인덱스다. 이것을 우리는 dispatch tokens이라 부른다. 이와같이 waitFor()를 호출하는 스토어는 그것이 그 자신의 스테이트를 어떻게 업데이트 해야하는지 알려주기 위한 다른 스토어의 상태에 의존할 수 있다.
디스패처 토큰은 디스패처에 콜벡을 등록할 때 register()의 반환값이다.
PrependedTextStore.dispatchToken = Dispatcher.register(function (payload) {
// ...
});
waitFor()이나 actions, action creators 그리고 디스패처에 대해 더 자세한걸 원하면 Flux: Actions and the Dispatcher 를 보자.
'Develop' 카테고리의 다른 글
| Android Support Library란? (0) | 2016.06.02 |
|---|---|
| 안드로이드 엑티비티란? (0) | 2016.06.01 |
| 안드로이드 Context 개념 익히기 (0) | 2016.06.01 |
| Redis(레디스)의 구현과 내부 구조, 작동 원리 - 1 (0) | 2015.08.23 |
| nodejs로 Azure(애저) 클라우드 알림 허브 푸시알림 보내기 (0) | 2015.05.20 |
| 우분투 시작시 자동으로 특정 명령 실행하기. (0) | 2015.03.17 |
| 도커란 무엇인가 / Docker 컨테이너 / Docker 이미지 / LXC / 가상화 (0) | 2015.03.09 |
| 브라우저 위치 정보 받아오기 / HTML5 Geolocation API (0) | 2015.01.03 |
| 워드프레스 설치 준비하기 - 우분투와 MariaDB, Apache, PHP와 함께. (0) | 2014.12.31 |
| Pymongo tutorial (파이몽고 사용하기) / pymongo 번역 (0) | 2014.10.29 |