flux (flux로의 카툰 안내서 요약)

Subin·2020년 12월 19일

note

목록 보기

1/2

문제점: user interaction이 뷰(view)를 통해서 일어 났기 때문에 가끔씩 뷰가 모델을 업데이트 할 필요가 있었고 의존성(dependency) 때문에 모델이 다른 모델을 업데이트 해야 할 때도 있었음.

아주 많은 다른 변경을 발생시킬 가능성
변경들이 비동기적으로 생길 수 있음
하나의 변경이 다수의 변경들을 일으킬 수 있음
--> action 을 통제하기 힘듦

해결책 : 단방향 데이터 흐름(unidirectional data flow)

the action creator

모든 변경사항과 사용자와의 상호작용이 거쳐가야 하는 액션의 생성을 담당하고 있다. 언제든 애플리케이션의 상태를 변경하거나 뷰를 업데이트하고 싶다면 액션을 생성해야만 한다.
일단 액션 생성자가 액션 메시지를 생성한 뒤에는 디스패쳐(dispatcher)로 넘겨준다.

dispatcher

디스패쳐는 기본적으로 콜백(callback)이 등록되어있는 곳이다. 이것은 마치 전화 교환대에서 교환원이 일하는 것과 같다 – [전화 교환대에서는 등록된 모든 전화들과의 연결이 가능하다]. 디스패쳐는 액션을 보낼 필요가 있는 모든 스토어(store)를 가지고 있고, 액션 생성자로부터 액션이 넘어오면 여러 스토어에 액션을 보낸다.

Flux의 디스패쳐는 다른 아키텍처들과는 조금 다른 점이 있다. 바로 액션 타입과는 관계없이 등록된 모든 스토어로 보내진다는 점이다. 이말인 즉슨, 스토어가 특정 액션만 구독(subscribe)하지 않고 모든 액션을 일단 받은 뒤 처리할지 말지를 결정한다는 뜻이다.

store

스토어는 마치 모든 것을 관리하는 정부관료와 같다. 모든 상태 변경은 반드시 스토어에 의해서 결정되어야만 하며, 상태 변경을 위한 요청을 스토어에 직접 보낼 순 없다. 스토어에는 설정자(setter)가 존재하지 않으므로, 상태 변경을 요청하기 위해서는 반드시 모든 정해진 절차를 따라야만 한다… 다시말해, 무조건 액션 생성자/디스패쳐 파이프라인을 거쳐서 액션을 보내야만 한다.

일단 스토어에 상태 변경을 완료하고 나면, 변경 이벤트(change event)를 내보낸다. 이 이벤트는 컨트롤러 뷰(the controller view)에 상태가 변경했다는 것을 알려주게 된다.

the controller view 와 the view

뷰는 상태를 상태를 가져오고 유저에게 보여주고 입력받을 화면을 렌더링하는 역할을 맡는다.

뷰는 발표자와 같다. 애플리케이션 내부에 대해서는 아는 것이 없지만, 받은 데이터를 처리해서 사람들이 이해할 수 있는 포맷(HTML)으로 어떻게 바꾸는지 알고 있다.

컨트롤러 뷰는 스토어와 뷰 사이의 중간관리자같은 역할을 한다. 상태가 변경되었을 때 스토어가 그 사실을 컨트롤러 뷰에게 알려주면, 컨트롤러 뷰는 자신의 아래에 있는 모든 뷰에게 새로운 상태를 넘겨준다.

어떻게 함께 동작하는가

준비

스토어는 디스패쳐에 액션이 들어오면 알려달라고 말해둔다.
컨트롤러 뷰는 스토어에게 최신 상태를 묻는다.
스토어가 컨트롤러 뷰에게 상태를 주면 렌더링하기 위한 모든 자식을 뷰에게 상태를 넘겨준다
컨트롤러 뷰는 스토어에게 상태가 바뀔 때 알려달라고 다시 부탁한다

데이터 흐름
준비과정이 끝나면 애플리케이션은 유저 입력을 위한 준비가 완료된다. 사용자의 입력으로 인한 액션이 생겼을 경우를 보자.

뷰는 액션 생성자에게 액션을 준비하라고 말한다.
액션 생성자는 액션을 포맷에 맞게 만들어서 디스패쳐에 넘겨준다.
디스패쳐는 들어온 액션의 순서에 따라 알맞은 스토어로 보낸다. 각 스토어는 모든 액션을 받게 되지만 필요한 액션만을 골라서 상태를 필요에 맞게 변경한다.
상태 변경이 완료되면 스토어는 자신을 구독(subscribe)하고 있는 컨트롤러 뷰에게 그 사실을 알린다.
연락을 받은 컨트롤러 뷰들은 스토어에게 변경된 상태를 요청한다.
스토어가 새로운 상태를 넘겨주면, 컨트롤러 뷰는 자신 아래의 모든 뷰에게 새로운 상태에 맞게 렌더링하라고 알린다.