리덕스나 리액트 관련 상태관리 라이브러리를 사용하다보면 자연스레 FLUX 패턴에 대해 접하게 되는데요,
리액트에서 State로만 상태를 관리하는 경우, props drilling과 같은 문제가 생기곤 했습니다.
저는 이런 불편함을 해결하기 위해 리덕스를 사용했었는데요,
리덕스에서는 사용상태가 store까지 상태 변화가 단방향으로 흐르고 action ➡️ dispatch 를 해야한다고 배웠었습니다. 이 관련된 방법들이 FLUX 패턴이 연관이 있다고 하는데 오늘은 FLUX의 등장배경와 어떤 개념인지에 대해 포스팅하고자 합니다.
이 포스팅은 MVC 패턴에 대한 이해를 기반으로 작성되었습니다.
배경
배경을 설명하기 이전에 FLUX가 등장한 이유는 프로그램의 흐름에 대한 예측가능성을 높이기 위해서 입니다.
FLUX 패턴이 있기 이전에 MVC 패턴이 존재했습니다. MVC패턴은 Controller를 이용해서 Model의 데이터를 CRUD합니다. Model의 데이터가 변동되면 View로 전달하여 다시 렌더링이 이루어지게 됩니다.
MVC 패턴에서 중요한 점은 데이터가 양방향 으로 흐를 수 있었습니다.
사용자가 View를 통해서 데이터를 입력하면 View역시 Model를 업데이트 할 수 있었기 때문입니다.
MVC 패턴같은 경우 패턴이 단순하기 때문에 보편적으로 많이 사용되었습니다.
하지만 단점으로는 MVC 패턴이 점점 더 많은 View, Model이 생기게 되면 즉, 큰 규모가 될수록 데이터의 흐름을 관리하기 쉽지 않았습니다. 사진과 같이 점점 Model과 View가 많아지면서 어떤 View가 Model의 데이터를 변화시킨것인지, 또 Model이 변화한 뒤 어떤 View를 렌더링 해야하는지 예측하고 판단하기 어려워졌습니다. 그렇다 보니 오류가 생겼을 경우에도 이를 추적하기가 어려워지게 되었습니다.
MVC는 코드 유지보수에 좋은 간단한 패턴이었지만, 규모가 큰 프로젝트일수록 MVC패턴은 적합하지 않았던 것입니다. 게다가 프론트엔드는 View가 굉장히 많아지기 때문에 MVC패턴은 적합하지 않았습니다. 그래서 다른 대안이 필요했습니다.
실제로 Facebook은 MVC는 정말 눈 깜짝할 사이에 복잡해진다 고 말하며 이 문제의 해결 방안으로 단방향 데이터 흐름을 가지는 Flux 패턴을 고안해냈습니다.
FLUX 패턴
Flux는 사용자 입력을 기반으로 Action을 만들고 Action을 Dispatcher에 전달하여 Store(Model)의 데이터를 변경한 뒤 View에 반영하는 단방향의 흐름으로 애플리케이션을 만드는 아키텍처입니다.
- 역할
- Action: Dispatcher에 전달되는 객체로, 쉽게 말해 데이터를 가변시킬수있는 종류
- Dispatcher: Action의 종류를 보고 Action에 맞게 데이터를 가공하거나 업데이트하는 역할
- Model: 데이터가 저장된 장소
- View: 사용자에게 보여지는 UI 역할
Action
Action이란 데이터를 변경하는 행위로서 Dispatcher에게 전달되는 객체를 말합니다. Action creator 메서드는 새로 발생한 Action의 타입(type)과 새로운 데이터(payload)를 묶어 Dispatcher에게 전달합니다.
{
type: 'SET_PROFILE',
data: {
'name': 'Harry',
'age': 458
}
}Dispatcher
Dispatcher는 모든 데이터의 흐름을 관리하는 중앙 허브입니다. Dispatcher에는 Store들이 등록해놓은 Action 타입마다의 콜백 함수들이 존재합니다. Action을 감지하면 Store들이 각 타입에 맞는 Store의 콜백 함수를 실행합니다. Store의 데이터를 조작하는 것은 오직 Dispatcher를 통해서만 가능합니다. 또한 Store들 사이에 의존성이 있는 상황에서도 순서에 맞게 콜백 함수를 순차적으로 처리할 수 있도록 관리합니다.
Store (Model)
Store는 상태 저장소로서 상태와 상태를 변경할 수 있는 메서드를 가지고 있습니다. 어떤 타입의 Action이 발생했는지에 따라 그에 맞는 데이터 변경을 수행하는 콜백 함수를 Dispatcher에 등록합니다. Dispatcher에서 콜백 함수를 실행하여 상태가 변경되면 View에게 데이터가 변경되었음을 알립니다.
View
View는 리액트 컴포넌트로 생각하면 됩니다. Store에서 View에게 상태가 변경되었음을 알려주면 최상위 View(Controller View)는 Store에서 데이터를 가져와 자식 View에게 내려보냅니다. 새로운 데이터를 받은 View는 화면을 리렌더링합니다. 또한 사용자가 View에 어떤한 조작을 하면 그에 해당하는 Action을 생성합니다.
여러 블로그를 찾아보았을 때, action객체가 무엇인지? 또 dispatcher란 무엇인지에 대한 이론적인 내용만 보면 이해하기 힘들 수 있습니다.
예를 들어, 제가 게임을 한다고 가정해보겠습니다. 상대방을 공격해 피를 깎아내야 이기는 철권을 한다고 해볼게요.
먼저 상대의 피는 100이라고 화면에 보이지고 있습니다. 즉, 이 100은 데이터를 뜻합니다.
하지만 제가 여러 버튼을 눌렀을 때 공격이 가동됩니다. 버튼 1을 누르면 발차기, 2를 누르면 주먹날리기 이런 것들이 있는데요. 어떤 버튼을 눌러야하는지 이런 목록들을 action(action 객체)이라고 볼 수 있습니다.
제가 이 버튼을 눌러 공격하게 되면 상대의 피가 깎이겠죠?
그 순간 dispatcher는 제가 누른 버튼이 무엇인지(어떤 action인지, 즉 어떤 공격인지) 데이터를 갖고있는 store에게 전달합니다.
store은 공격을 확인하고 피를 깎습니다. (store의 변화)
이후 store에 있는 변화된 데이터를 View에 전달하고 View는 피가 깎인 80의 데이터를 보여줍니다.
이런식으로 어떠한 action이 발생했는지 dispatcher는 store에 전달하고 store은 변화된 데이터를 view에게 전달합니다.
각 요소들은 단방향 흐름에 따라 순서대로 역할을 수행하고, View로부터 새로운 데이터 변경이 생기면 처음부터 다시 이 순서대로 실행합니다. 이렇게 함으로써 예외 없이 데이터를 처리할 수 있게 되었습니다.
