[React/State/Props] MVC 모델과 Flux모델 , React의 선택

React의 핵심은 "상태(state)"를 어떻게 잘 관리하냐는 것입니다. TodoList를 짜면서도 느낀거지만, 기본적으로 state는 setState로 비동기로 관리하게 되고, 불변성을 만족하는 등의 일종의 제약조건이 있게 됩니다.

 

React는 화면과 데이터를 일치시키기 위해서, 다른 말로 하면 실시간 렌더링을 위해서 , Flux패턴을 채용했습니다.

상태 끌어올리기를 이해하기 위해서는, React의 기본적인 데이터의 흐름에 대해서 이해해봅시다!

React의 데이터 흐름을 이해하기 전에, 간단하게 90's부터 이어져온 ,전통적인 Web Model에서의 Data 흐름을 봅시다. 그래야 React가 왜 FLux를 썻는지 더 잘 와닿습니다.

 

전통적인 Web Model (MVC)

React 또한 MVC 모델을 처음에는 사용했었습니다. 우선 , MVC모델이 뭔지 간단하게 짚고 넘어가봅시다.

 

* MVC 모델

시스템을 Model ,View,Controller 3가지의 영역으로 나누어서 설계하는 방법을 이야기합니다.

Model은 데이터를, Controller는 웹에서 발생하는 로직,이벤트를 담당하고 , view는 보여주는것만을 담당하게 됩니다. 물론, 각자 서로에게 정보를 알리기 위한 로직은 구현되어야 합니다. 순수하게 "데이터"만 들어가있거나, "보여주는것"만 들어있는게 아닙니다.

예를들어, 채팅 시스템이라고 생각해봅시다.

view는 "채팅창"을 담당합니다. 이때, 어떤 채팅창을 그려줄 것인지 , font는 어떻고 배경이미지는 어떻고 , 문자들의 배열은 어떻게 보여줄 건지  등을 담당합니다.

Model은 채팅내용,서로의 이름, 보낸시간, 확인여부, 읽었는지 안읽었는지의 정보,채팅창끼리 서로의 소켓 등등 필요한 모든 정보를 담고있을겁니다.

Controller는 채팅창을 열어(생성)주고, 소켓을 생성하여 통신을 하게 해주고, Model이 담고 있는 데이터들을 view에게 건네주는 등, Model과 view사이를 중재해주는 역할을 합니다.

 

MVC의 문제점 (어떤 것이든지 ,크면 문제다)

 

MVC는 서로의 독립성을 보장하여 설계되기 때문에 유지보수에도 용이하고, 확장성에도 좋습니다. 하지만, "확장성"이 좋은만큼 확장했을 때의 문제점이 나타나게 됩니다. 여러가지 Model이 여러가지 View에 사용될 수 있습니다. 하지만, 여러가지 Model이 다양한 View에 서로 묶이게되면, model간의 의존성이 생기게 됩니다.

Facebook은 chatTab과 mainChatView등 여러가지 view가 존재했고, view의 입력에 따라서 Model을 업데이트가 필요한 경우도 있었습니다. 예를 들어, 좋아요를 클릭하면 해당 게시물의 좋아요는 +1을 해주는 등의 동작이 이에 해당하겠네요.

즉 ,하나의 "View"에서 다른 여러가지 Model들의 데이터가 변경되는 "의존성"을 가지게 되어버립니다.

 

그렇다고, Controller에 많은 로직을 집중시키면 유지보수가 매우 어렵게 되어버립니다.  유지보수를 좋게하기 위해서 MVC를 선택했는데 Controller가 무거워져서 , 유지보수가 어려워진다? 이건 넌센스한 상황이었습니다. 

View에서 model을 변경하는 양방향 데이터의 흐름은 점점 새로운 기능을 추가시키기 어렵게 만들었고, 의도하지 않은 에러들이 발생하게 되었습니다. 결국 ,  "데이터의 흐름"을 예측불가능하게 만들었습니다.

 

그래서, Facebook에서는 기초설계부터 잘못되었다는 걸 인정하고, MVC 모델을 과감하게 버리기로 합니다.  데이터의 흐름을 한 방향으로 고정시키는 "Flux"모델을 도입하게 됩니다.

Flux모델

데이터의 흐름을 한 방향으로 고정시켜 , 위와 같은 예측불가능하지 않은 "예측 가능한" 데이터 흐름을 만들어내게 됩니다.

View -> Action -> dispatcher -> store -> View 식으로 , 데이터가 한 방향으로 흐르게 합니다.

 

View

• 사용자에게 보여지는 화면입니다. 사용자를 통해서 입력을 받게되면 , Action을 발생시키게 됩니다.

Action (creator)

• View를 통해서 들어온 입력(Action)을 "dispatcher"가 알아들을 수 있는 적합한 형태로 만들어 줍니다.

Dispatcher

• callback이 등록되어있고, Action이 생성되면, dispatcher로 넘어가게 된다.
• dispatcher는 Action들을 Store에 보내주는 역할을 하는데, dispatcher는 액션을 보낼 필요가 있는 모든 store을 알고있고, 여러 스토어에 액션을 넘기게 됩니다. 

Store

• store는 모든 상태 변경을 담당하게 되는 최종 결정자입니다.
• View의 상태는 Store가 직접 변경하게 되고, view는 store에게 직접 요청을 할 수 없습니다. 오직 dispatcher에게 부탁을할 수 밖에 없습니다.

 

사실, 상태 끌어올리기와 상태 drilling , props의 흐름을 설명하기 위해서 앞에 설명을 붙이다보니, 글이 길어졌네요. 다음글로 넘기겠습니다! 

 

refer

FLUX에 대한 애니메이션

Facebook의 Flux 발표