Flux
Flux는 데이터 플로우를 관리하는 하나의 패턴이다. flux가 가지고 있는 가장 중요한 특징은 flux의 데이터 플로우는 단방향이라는 점이다.
구성요소
Dispatcher
디스패쳐는 액션을 받아 그것을 등록되어있는 스토어들에게 뿌려주는 역할을 수행한다. 모든 스토어는 빠짐없이 모든 액션을 받게 된다. 각 어플리케이션당 하나의 싱글톤 디스패쳐 객체만이 존재한다.
Store
스토어는 어플리케이션에서 사용하는 데이터를 가지고 관리한다. 스토어는 어플리케이션의 디스패쳐에 자기 자신을 등록해야한다. 왜냐하면 그렇게 해야만 액션을 받을 수 있게 되기 때문이다. 스토어에 저장되어있는 데이터는 액션에 의해서만 수정되도록 주의해야한다. 그 외의 다른 이유로 스토어의 데이터가 수정되어서는 안 된다. 따라서 setter 메소드는 주어져선 안되고, 오직 getter만 주어져야 한다. 스토어는 액션을 받고, 원하는 액션에 대해서만 반응한다. 여기서 또 주의할 것이 하나 있다. 스토어의 데이터에 변경이 일어났을 땐 무조건 "change" 이벤트를 뿌려야 한다. 스토어는 하나의 어플리케이션에 무수히 존재할 수 있다.
Action
액션은 어플리케이션 내부에서 사용하는 일종의 API라고 볼 수 있다. 어플리케이션과 유저 간에 일어나는 모든 상호작용이 바로 액션이다. 액션은 간단한 자바스크립트 객체로 'type' 필드와 그 외의 여러 데이터 필드들을 가질 수 있다.
액션은 상세 구현보다 좀 더 추상화한 개념의 이름을 붙여야 된다. 가령 예를 들어 로그인 액션이 존재한다고 하면 이 액션의 type은 'create-user-session', 'get-user-info' 따위가 아니라 'login-user' 처럼 모두 포괄할 수 있는 이름이어야 한다. 이유는 다음과 같다. 앞서 모든 스토어가 모든 액션을 받는다고 했는데, 같은 액션이라도 스토어에 따라서 실질적으로 수행하는 작업이 달라질 수 있기 때문이다. 위에서 말한 예제에 맞춰서 생각해보자. 만약 'login-user' 액션이 각 스토어들에게 뿌려진다면 session 스토어는 액션에 대응해서 새로운 유저 세션을 만들 것이고, user 스토어는 해당 유저 데이터를 서버에서 받아올 것이다.
View
스토어에서 가지고 있는 데이터를 보여주는 역할. 뷰는 무슨 프레임워크를 쓰든 사실 상관 없다. 물론, 보통 flux를 쓰는 입장이라면 react를 쓰고 있을 확률이 높긴 하다. 스토어에 있는 데이터를 사용하기 위해 뷰는 스토어의 'change' 이벤트를 subscribe 해야 한다. 이렇게 해야 뷰는 스토어의 데이터가 변경되었다는 것을 감지하여 새로운 데이터를 바탕으로 다시 렌더링할 수 있게 된다. 만약에 스토어의 데이터를 바로 끌어다 쓰고 이벤트를 subscribe하지 않는다면 미묘한 버그들이 발생할 수 있다. 뷰에서 유저와 상호작용이 일어남에 따라 보통 액션은 뷰에서 디스패쳐로 전해지기 마련이다.
데이터 플로우
- 뷰에서 어떤 액션이 디스패쳐로 전해진다.
- 디스패쳐는 해당 액션을 모든 스토어로 뿌린다.
- 스토어는 액션을 보고 정해진 동작을 수행하여 만약 데이터에 변경이 생겼다면 뷰에게 이것을 전파한다.
물론, 위에서 보다시피 액션은 항상 뷰에서 시작하는 것은 아니고 다른 원인으로 시작할 수도 있다. 그러나 보통은 뷰에서 시작되기 마련이다.