MVC 패턴의 문제점
Flux 패턴은 페이스북이 Single Page Applications를 제작하기 위해 제안한 패턴 중 하나이다. 이전 페이스북의 Client Side가 MVC 패턴으로 동작했을 때, 유저가 현재 읽지 않은 알람의 개수가 동적으로 관리되지 않는 버그를 갖고 있었다. 페이스북은 해당 문제를 MVC 아키텍처 어플리케이션의 규모가 커질 때 발생한다고 판단했다.
위 그림은 MVC 아키텍처에서 데이터가 어떻게 전달되는지 보여준다. 하지만 서비스의 규모가 커져 Model과 View가 많아지면 어떤 형태가 될까?
아래 그림을 보면 모델과 뷰의 관계가 복잡하게 얽혀 있는 것을 알 수 있다. 이런 상황에서 데이터가 변경이 되면 그 데이터와 연관이 있는 모든 뷰가 변경되어야 한다. 이 과정에서 발생하는 데이터의 흐름이 상당히 복잡해진다.
Flux 패턴은 다양한 컴포넌트에 걸쳐 발생하는 양방향 데이터 흐름을 제어하기 위해 등장했다. 페이스북이 제시한 Flux의 경우 어플리케이션은 store, dispatcher, views, actions/action generator로 구성된다.
Flux패턴의 동작 방식
flux 패턴에서 데이터는 아래와 같은 순서로 동작한다.
1. 사용자가 view를 조작한다.
2. view가 action generator를 통해 action을 생성한다.
3. view가 생성한 action을 dispatcher에 전달한다.
4. dispatcher는 전달 받은 action의 type, payload을 통해 store을 변경한다.
Flux 패턴을 활용함으로서 클라이언트 사이드에서 데이터를 단방향으로 제어할 수 있게 되었다.
이제 Flux 패턴의 각 요소를 조금 더 자세히 살펴보자.
Flux의 구성요소
1. Store
React에서 state가 컴포넌의 데이터를 관리하는 변수라면, Store는 어플리케이션 단위에서 State를 전역적으로 관리하기 위한 객체이다. 전역적으로 상태를 관리하다 보면, 오염에 취약해진다. Flux는 전역 상태의 무결성을 위해 Dispatch를 통해서만 변경된다.
2. Dispatcher
Dispatcher는 actions을 통해 Store를 변경한다. Redux에서는 Dispatcher 대신 Reducer라는 함수를 통해 action을 처리한다. Reducer는 순수함수이기 때문에, 외부 변수에 의존해서도 안되고, 같은 입력에 대해서 항상 동일한 출력을 내보내야 한다. 덕분에 store를 더욱 통제된 방식으로 관리할 수 있다.
3. View
View는 유저 인터페이스 컴포넌트로, 유저는 View를 통해 데이터를 확인하고 조작할 수 있다. Redux의 개발자는 또한 view를 Container view와 Presentational view로 구분하는 패턴을 권장했다. container view는 store와 직접적으로 연결되어 데이터를 불러와 presentational view로 전달한다. presentational view는 container view로부터 전달받은 데이터를 표현하는데 집중한다.
4. Actions
Acition은 store를 변경할 내용을 담고 있는 객체이다. store에는 수정할 Domain과 수행할 작업에 대한 이름 그리고 수정에 반영될 데이터인 payload가 담겨있다. action을 더욱 엄격하게 관리하기 위해 action은 action generator를 통해 생성한다.
Redux
Flux는 페이스북이 여러 컴포넌트에 걸쳐 사용되는 데이터를 단방향으로 관리하기 위해 제안된 패턴이다. Redux는 Flux 패턴을 React에서 사용하기 위해 고안된 라이브러리이다. Redux의 개발자 Dan Abramov는 redux를 다양한 컴포넌트에 걸쳐 동일한 데이터를 사용하기 위해 Redux를 사용한다고 말했다.
Dan Abramov의 코딩 인터뷰
div 블록을 화면 정 가운데에 정렬하는 과정이 상당히 인상깊다.
