flux패턴

mvc패턴의 한계로 페이스북이 만든 “읽은 표시(mark seen)”에 관해 많은 뷰가 있다면 이를 어떻게 처리해야 할까?
어떤 페이지에서 메시지를 읽었는데 다른 페이지에서는 메시지가 안 읽었다고 뜨는 경우가 발생한다.
그 이유는 V와 C의 관계가 복잡해지니 버그를 수정하기도 데이터흐름을 알아보기 어려운 문제가 발생한다.
예를 들어 View에서 일어난 것이 모델에 영향을 끼치기도 그 반대도 영향을 미치는 로직도 있는 상황이 발생하여 데이터를 일관성 있게 뷰에 공유하기가 어렵다.

그렇기 때문에 해결방법으로 데이터가 “한방향”으로만 흐르게 flux 패턴이 나오게 되었고, action, dispatcher, store이라는 계층이 있다.

Action

마우스 클릭이나, 글을 쓴다던가 이벤트를 의미하며 이벤트가 발생했을 때 action에 관한 객체를 만들어내 dispatcher에게 전달한다.

Dispatcher

들어오는 Action 객체 정보를 기반 어떠한 “행위”를 할 것인지, 보통 action객체의 type를 기반으로 미리 만들어 놓은 로직을 수행한다. (보통 switch를 써서 함.)

Store

데이터, 상태를 담고 있는 계층

flux 패턴의 장점

• 데이터 일관성의 증대
• 버그를 찾기가 쉬워진다.
• 단위테스팅이 쉬워진다.

flux패턴이 적용된 redux

const initialState = { visibilityFilter: 'SHOW_ALL', todos: []
}
function appReducer(state = initialState, action) { switch (action.type) {
case 'SET_VISIBILITY_FILTER': { return Object.assign({}, state, { visibilityFilter: action.filter
}) }
case 'ADD_TODO': {
return Object.assign({}, state, {
          todos: state.todos.concat({
            id: action.id,
            text: action.text,
            completed: false
})
  }) }
case 'TOGGLE_TODO': {
return Object.assign({}, state, {
todos: state.todos.map(todo => { if (todo.id !== action.id) {
return todo }
return Object.assign({}, todo, { completed: !todo.completed
}) })
}) }
case 'EDIT_TODO': {
return Object.assign({}, state, {
todos: state.todos.map(todo => { if (todo.id !== action.id) {
return todo }
return Object.assign({}, todo, { text: action.text
}) })
}) }
default: return state
} }

앞의 코드처럼 switch를 통해 action의 type을 통해 판단 각각의 행위를 결정하는 것을 볼 수 있다.