Context와 hook, props 상속

• Props Drilling Problem이 문제라면 새로운 개념을 만들기보다 props만 새로 뚫지 않는 방법등을 제공하면 되지 않느냐는 시각입니다.
• 컴포넌트 트리에서 Context라는 거대한 공통 조상을 만들고 그 Context로 부터 데이터를 제공을 받는 방식입니다.
• 개념적으로는 별도의 Store를 두는 FLUX와 비슷한 느낌이 있어서 최근에는 복잡한 문법을 가지고 만들어야 하는 Redux보다는 React의 기본 기능인 Context API를 쓰겠다는 움직임이 생기고 있습니다.
• Svelte에서도 React와 동일한 Context라는 개념을 제공하고 있습니다.
• 또한 별도의 props를 선언하지 않고 모든 props를 자식으로 전달해주는 기능들도 제공하고 있습니다.

개선방향

• View와 Model은 분리한다.
• 프레임워크에서 Props Drilling Problem를 막는 방법을 제공하자!

Atomic 패턴 - Recoil, Svelte Store, Vue Composition, jotai

• 거대한 View영역과 Store영역을 나누어 이분법으로 생각하자는 의견에는 동의하나 Action ~ Dispatch ~ Reducer와 같은 복잡한 구조를 가져야 하는가에 대한 방법에 대해서는 회의적인 시각으로 만들어진 방법입니다.
• 간단한 문법으로 컴포넌트 외부에서 공통의 데이터를 set, get을 할 수 있게 하면서 동시에 동기화를 할 수 있는 방향성입니다.
• 이와 더불어 computed, derived, select 와 같은 반응형 기능을 제공하여 관련된 데이터의 동시 업데이트를 제공하고 있습니다.

개선방향

• View와 Model은 분리한다.
• 중간의 과정은 자율에 맡기고 간단하게 Model에 접근하는 법만 제공하자.
• 동기화, 동시성 처리가 중요

React-Query - MVC의 개념 확대

• React-Query는 이러한 상태관리에 편향되어 있던 시각에서 벗어나 고전적인 ajax의 데이터를 Model로 간주합니다.
• 대부분의 프론트엔드 개발은 서버 데이터를 CRUD하고 시각으로 그리는 것에 중점이 되어 있는데 FLUX나 Atomic은 너무 복잡한 방법이라는 것입니다.

React Query는

• 서버와의 fetch 영역을 Model로 간주
• View는 React
• Controller는 query와 mutation이라는 2가지의 인터페이스를 통해서 서버 데이터의 상태를 관리하고 캐싱, 동기화, refetch등을 관리해주는 역할

을 통해서 기존의 복잡함을 덜어내었습니다.

사실 이름은 중요하지 않다. MV*

• MVC, MVVM, FLUX, MVI, Atomic, Obserable...
• 현재 쓰고 있는 라이브러리들이 저런 아키텍쳐에 딱 맞게 떨어지지는 않습니다.
• 아키텍쳐는 비슷한 것들을 묶어서 기존과는 다른 이름을 붙이면 우리가 개념의 범주를 만들기 좋게 하기 위한 일종의 마인드셋입니다.
• 어떤 이름들은 라이브러리가 출시가 되고 나서 설명을 하기 위해서 만들어졌고, 어떤 이름들은 전략적으로 이전과는 다른 차별화를 강조하기 위해서 이름을 새로 짓기도 합니다.

• 앵귤러는 아예 MVW (Model-View-Whatever) 혹은 MV* 로 불러달라고 했습니다.
• 뭐가 되었든 Model과 View 사이에서 무언가를 할테니까요.

각 아키텍쳐의 이름보다는 웹 프론트엔드의 막연히라도 전반적인 아키텍쳐의 구성과 변화의 흐름을 이해해서 아키텍쳐의 본래 이유였던 지속적으로 잘 관리되는 코드를 짜기 위해서 지금 쓰는 아키텍쳐에 맞는 방식으로 더 코드를 잘 작성할 수 있는 기반 지식이 되었으면 합니다.

출처

https://velog.io/@teo/프론트엔드에서-MV-아키텍쳐란-무엇인가요#프롤로그