MVC 패턴과 Flux 패턴 이해하기
Zustand와 Jotai은 같은 개발자에 의해 만들어진 상태관리 라이브러리인데 왜 다른 방식을 채택했을까? 라는 궁금증이 생겨
이에 대해 알아보기 위한 배경 지식을 먼저 정리하고자 한다.
도서관리 어플리케이션을 예시로 각 패턴을 이해해보려고 한다
리덕스가 등장하기 이전 프론트엔드에서 데이터의 흐름을 관리하는 방식은 MVC 패턴이었다.
[MVC 패턴]
🎁Model은 데이터와 관련된 모든 것을 관리한다. (상태 저장 및 관리)
📊View는 사용자에게 데이터를 보여주는 역할을 한다
🕹️Controller는 모델과 뷰 사이의 중재자 역할
사용자 입력을 받아 모델을 업데이트하고 & 모델의 변경 사항을 뷰에 반영한다.
데이터 흐름
1. 사용자가 웹 페이지 (뷰)에서 새 책 추가 버튼을 클릭하고 책 정보를 입력
2. 입력된 정보가 컨트롤러로 전달
3. 컨트롤러는 이 정보를 받아 Book 모델을 생성 또는 업데이트
4. 모델이 업데이트되면 컨트롤러는 변경된 모델 데이터를 뷰에 전달
5. 뷰는 업데이트된 도서 목록을 사용자에게 보여준다.
[여러 개의 모델과 뷰가 존재하는 경우]
하나의 모델과 뷰가 변경되었는데 다른 모델과 뷰가 같이 변경되는 경우 예시
모델의 변경이 뷰에 영향을 미치고, 뷰의 입력이 모델에 영향을 미치는 모습을 볼 수 있다. (양방향 데이터 흐름)
이러한 상호작용이 어플리케이션 복잡성을 증가시키고, 모델간의 의존성이 많을수록 관리가 어려워진다
상태 관리와 데이터 흐름을 명확하게 하기 위해 단방향 데이터 흐름 패턴 (Flux, Redux) 을 도입하게 되었다.
[Flux 패턴]
Action 이 발생하면 Dispatcher로 전달되고, Dispatch는 전달된 Action을 보고 등록된 콜백 함수를 실행하여 Store에 데이터를 전달한다
📊View : 사용자에게 데이터를 표시하고, 사용자 입력을 받아 액션을 생성한다.
뷰는 스토어의 상태를 구독하고, 상태가 변경되면 UI를 업데이트한다.
✏️Action : 애플리케이션에서 발생하는 모든 이벤트를 나타낸다.
Dispatcher에서 콜백함수가 실행되면 Store가 업데이트 된다. 이 콜백함수를 실행할때 데이터가 담겨있는 객체가 인수로 전달되어야 하는데 이 전달되는 객체를 Action이라고 한다.
📢Dispatcher : 모든 데이터 흐름을 관리하는 역할
모든 Action을 중앙에서 관리하고 이를 모든 스토어에 전달한다.
🎁Store : 애플리케이션의 상태를 관리한다. (상태를 저장하고 변경사항을 관리)
모든 액션을 받아서 자신에게 적합한 액션이 어떤건지 필터링한다. 이후 상태값을 변경하고 View에게 변경되었다는 사실을 알려주게 된다.
위에서 살펴본 예시를 Flux 패턴을 적용한 경우로 다시 살펴보았다.
확실히 디스패쳐가 중앙에서 모든 액션을 관리하여 관련 스토어에 전달하므로 데이터 흐름이 명확해보인다.
그동안 MVC, Flux 패턴을 들어는 봤지만 데이터 흐름이 어떻게 되는지, 어떤 점이 다른지 전혀 모르는 상태였는데 이렇게 도식화를 해보면서 조금은 이해를 하게 된 것 같다.
Redux, Recoil, Zustand, Jotai 등 상태 관리 라이브러리의 동작 원리에 대해서도 계속해서 공부해봐야겠다.
