저번에도 공부를 했지만 이해사 100퍼까지 바라지도 않음.. 70퍼 정도는 이해가 가야 뭘 써먹지 할텐데, 70퍼도 이해가 가지 않음.. 근데 미니 프로젝트 하면서 useContext를 사용해서 전역데이터를 사용해 봤는데, 확실히 편하긴함!

특히 제일 좋은점은 자식 컴포넌트에게 props를 전달 전달 전달 하지 않고 바로 자식컴포넌트에서 불러올 수 있다는점! 이게 제일 큰 강점이 아닐까!

하지만 이 또한도 useContext의 한계점이 있기때문에 Redux, Recoil, Jotai와 같은 상태관리 라이브러리가 나오는것 같다. 나는 그 한계점과 Flux구조에 대한 이해가 조금 부족해서 이 부분을 위주로 포스팅을 해보려 함.

🔶 MVC구조 (Model-View-Controller)

🔹 MVC 기본구조

• Model

  • 데이터와 관련된 내용을 담고 있음. 또한 데이터를 관리하는 로직도 포함하고 있음.
  • Model은 UI와 직접적으로 연결되지 않음. Model은 받아온 데이터를 그에 맞춰 저장할 형태를 만드는 것이 중요함.

• Controller

  • Controller는 앱의 핵심 로직을 담고 있는 계층. View, Model에 연결되어 그 중간의 역할을 하고 있음.
  • Controller는 해당 View마다 하나씩 붙어서 그 View에 맞는 로직을 포함하고 있기 때문에, 재사용성은 View보다 훨씬 떨어진다.

• View

  • UI. 유저들에게 데이터를 보여주고, 어떻게 보여줄지 화면을 구성하는 코드들이 포함
  • View는 기본적으로 Controller로 부터 정리된 데이터를 받아서 화면에 보여주는 역활을 함.

예를들어 , input을 사용자가 로그인을 한다고 가정했을 때, 로그인 정보에 맞지않아 애러가 났다.

• Controller : 로그인의 정보 데이터를 담고 있다.
• Model: 로그인 입력 값을 받아서, controller가 담고있는 값과 비교하며, 어떤 애러메세지를 띄울 지 view에게 알려준다.
• View : 애러가 났을 때, 모달을 띄울건지, alert을 띄울건지, 어떻게 애러 메세지를 보여줄건지 보여준다.

🔹MVC 구조의 한계

MVC구조는 View, Controller를 중심으로 한 디자인패턴이고, View Controller 하나가 화면 하나를 끌고 가고 있었다. SPA 일 경우 하나의 페이지에서 계속해서 렌더링 되기 떄문에 Model과 View의 변화가 위의 그림처럼 복잡하게 되어버린다.

예를들어, 유저들의 모든 정보들을 담고있는 Controller가 있다.
유저가 포스트를 삭제 하려고 한다.

• Step1 :
  • view: 10개 있던 포스트를 9개만 보여준다.
  • model : user의 포스트 정보를 10 개에서 9개로 바꾼다.
• Step2 :
  • view: 유저 info가 있는 포스트 갯수가 10 개였다고 하면 삭제한다면 9개가 된다. 9로 바꿔준다.(Post: 10, Review: 15 이런 구조)
• Step3 :
  - Post 갯수를 갖고 있는 View들은 모두 Post의 Model을 참조하게 된다.
  

이렇게 리액트 구조 안에서 MVC구조는 하나가 변경 될 경우 많은 부분의 View와 Model을 참조하므로 복잡해지고, 유지보수 하기가 힘들어진다.

페이스북에서 참조한 사례로는, 페이스북에서 안 읽은 갯수를 표시할 때, 사용자가 읽지 않았던 글을 읽으면 그만큼 숫자를 빼는 단순한 기능임에도, MVC로 구현되었을 때 모델별로 데이터를 가지고 있는 부분이 다르기 때문에 이것들을 싱크하거나 동시에 업데이트 해야하는 불편한 관계가 있다고 한다.

그래서 페이스북 개발팀은 MVC를 버리고 Flux 아키텍처를 적용하기로 한다.

✨ FLUX 구조

🔹 FLUX 구조와 데이터흐름

Flux 어플리케이션에서의 데이터는 단방향으로 흐른다.

dispatcher,store와 view는 독립적인 노드로 입력과 출력이 완전히 구분된다. action은 새로운 데이터를 포함하고 있는 간단한 객체로, type 프로퍼티로 구분할 수 있다.

• Action / Action Creator
  • Store상태를 변경할 수 있는 호출카드 같은 것.
  • 디스패쳐의 특정 메소드를 실행하면 스토어에 변화를 일으킬 수 있는데, 이 메서드를 호출할때는 데이터 묶음을 파라미터로 전달한다. 이 데이터 묶음을 Action이라 한다.
  • 디스패치에 전달할 액션 객체는 대체로 액션 생성자(Action creator)라는 함수 또는 메소드를 통해 만들어진다.
• Dispatcher
  • Flux 어플리케이션의 모든 데이터 흐름을 관리하는 허브 역활을 한다.
  • 액션이 발생하면 디스패쳐로 액션객체가 전달되고 디스패처에 등록된 콜백 함수를 통해 이 액션객체를 스토어에 전달한다.
  • 디스패처는 한개의 instance 만 사용한다.
• Store
  • 스토어는 애플리케이션 상태를 저장한다.
  • 애플리케이션의 특정 도메인에 해당하는 상태를 다룬다. 상태를 다루기 때문에 무엇이든 저장할 수 있고, 단순한 Object로 구성되어 있다.
  • 상태변경 요청을 스토어에 직접 보낼 수 없으며, 액션생성자 또는 디스패쳐를 통해 액션을 보내야 수정이 가능해진다.
• View
  • 상태를 가져와서 보여주고 입력받을 화면을 보여줄 역할을 맡는다.

◼ 출처 및 참조

• [ MVC 패턴과 UIKit의 ViewController] : https://medium.com/hcleedev/ios-%EA%B0%9C%EB%B0%9C-mvc-%ED%8C%A8%ED%84%B4%EA%B3%BC-uikit%EC%9D%98-viewcontroller-3fdb52f6b4b8
• [Flux 사이트 Overview]
  https://haruair.github.io/flux/docs/overview.html