✍ 디자인 패턴에 대해

코드 레벨의 디자인. 소프트웨어를 구현할 때 반복되는 문제 상황들을 개선하기 위해 만든 규약

✅ 아키텍처

• 개발을 진행할 때 규칙을 만들어 가며 개발을 하다 보면 이를 통해 하나의 특정 패턴이 만들어진다.
• 코드를 지속적으로 수정, 관리하기 편한 방향으로
• 이러한 패턴들을 모두가 이해하고 따를 수 있도록 하는 구조를 아키텍처라고 한다.
• 디자인 패턴은 소프트웨어 아키텍처보다 작은 범위에 속한다.

✍ 프론트엔드 디자인 패턴

📖 MVC

• Model(데이터): 데이터와 비즈니스 로직을 처리
• View(화면): 유저가 보는 화면, 결과물
• Controller(컨트롤러): 유저의 입력이 들어오면, Model의 데이터를 변경/가공

MVC 패턴의 포인트

1. 화면을 제어하는 것과 데이터를 제어하는 것은 분리되어야 함
2. Model과 View간의 의존 관계를 최소화하여 서로에게 영향을 미치지 않게 함

MVC 패턴에서의 View는 단순히 화면을 보여주는 역할이다. 하지만 프론트엔드에서는 그 View에서 발생하는 수많은 이벤트를 처리하는 것이 중요하기 때문에, View의 중요성이 크지만 이 패턴에서는 이를 비중있게 다룰 수 없다. 때문에 프론트엔드 개발을 할 때 수많은 View들과 데이터, 그리고 이들의 소통을 위한 View와 Model 사이에서 일어나는 요청들을 Controller를 통해서 처리할 수밖에 없다. 따라서 Controller의 코드가 방대해지며, 관리하기 어려워진다는 단점이 있다.

📖 MVVM

• ViewModel - Model에서 데이터 변경이 일어나면 View에서도 자동으로 변경될 수 있게 함

개선점

• 컨트롤러의 반복적인 기능이 선언적인 방식으로 개선되었다.
• Model과 View의 관점을 분리하려 하지 않고 하나의 템플릿으로 관리하게 되었다.
• 화면 단위가 아닌, 재사용할 수 있는 조금 더 작은 단위로 분리한다.

MVC에서의 Controller가 ViewModel로 바뀐 형태라고 이해하면 된다. 기존의 Controller는 View에서 데이터를 요청할 때마다 기능을 반복적으로 수행했다면, ViewModel은 View와 데이터 바인딩이 되어있기 때문에 Model과 View에서 일어나는 변동사항들을 쉽게 처리할 수 있게 되었다. 이것은 MVC 모델에서 View와 Model이 단방향으로 소통하던 것을 해결하고, Controller가 방대해지는 것을 방지할 수 있다.

📖 FLUX, Redux

Props Drilling

컴포넌트 구조가 복잡해지면서, 하위에 특정 값을 전달하기 위해서 중간 레벨에 있는 컴포넌트들은 전부 그 Props를 가지고 있어야 한다.
하위 컴포넌트에 데이터를 보내주기 위해 다른 컴포넌트들이 불필요하게 Prop를 가지고 있어야 한다. 이는 데이터에 대한 에러를 찾기 힘들게 한다. 이러한 문제를 해결하기 위해 단방향 패턴인 FLUX가 등장하였다.

✅ FLUX

• Action 액션이란 어떤 행위인지와 그 행위로부터 넘겨받은 값들을 가진 하나의 객체이다. 여기에는 어떤 액션인지를 가리키는 type 과 넘겨받은 값인 payload가 담긴다. 액션 생성자는 해당 액션을 생성해서 Dispatcher에 넘긴다.

• Dispatcher 디스패쳐는 모든 액션들을 받아서 의존성을 적절히 처리한 다음 Store에 넘긴다. 모든 스토어가 모든 액션을 받게 된다.

• Store 스토어는 모든 액션을 받아서 자신에게 적합한 액션이 무엇인지 필터링한다. 그리고 상태값을 변경한 후 자신에게 연결된 Controller View(화면에 나타는 Child View들과 Store를 연결하는 매개체)에게 상태가 변화되었음을 알린다.

• View Child View들은 Controller View에게 변화된 상태를 전달받고 그 상태에 따라 다시 렌더링이 된다.

FLUX는 이러한 흐름을 설명하는 아키텍처일 뿐 실체가 있진 않다.

✅ Redux

Redux는 FLUX 패턴을 이용한 구현체이다.
View를 각각의 MVC 컴포넌트 관점으로 보는 것이 아니라 하나의 큰 View로 이해한다. View에서 발생한 동작을 Dispatch에 전달하면 Action은 데이터를 Store에 보관하고 Store에 들어있는 데이터는 다시 View로 연결이 되는 방식이다.

1. 사용자가 UI에서 이벤트를 dispatch 한다면, Redux store에 사용자의 이벤트 정보를 저장하는 Action이 전달됨
2. Store는 이전의 상태로부터 상태를 업데이트하는 Reducer 함수를 실행하고 새로운 State를 저장
3. Store가 현재 변경된 State를 구독하는 모든 UI들에게 스토어가 업데이트 됐음을 알림
4. 각 UI 구성 요소는 필요한 상태가 부분 업데이트 됐는지 확인하고 새 데이터로 다시 렌더링

📖 Atomic

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

📖 Concurrent UI

• React의 Concurrent UI Mode
• 사용자 경험 개선
• 우선순위에 따라 더 중요한 작업을 먼저 처리할 수 있음
• 서버와의 fetch 영역을 Model로 간주
• Controller는 query와 mutation이라는 2가지의 인터페이스를 통해서 서버 데이터의 상태를 관리하고 캐싱, 동기화, refetch 등을 관리해주는 역할

동작 원리

React가 컴포넌트의 일부를 처리하는 동안 다른 작업을 수행하는 방식
React가 컴포넌트 렌더링을 완료하기 전에 다른 작업을 수행할 수 있으므로, 사용자 경험이 더욱 개선된다.

Concurrent Mode에서의 React는 컴포넌트를 여러 단계별로 나누어 처리한다. 이 단계를 통해 브라우저 이벤트, 애니메이션, 사용자 입력 등 다른 비동기 작업에 대한 우선순위를 나누고 이 우선순위를 조절하며 작업을 수행한다 - 컴포넌트를 먼저 부분적으로 렌더링한 후, 브라우저에서 동시에 처리할 수 있는 다른 작업을 처리한다.

참고 자료

프론트엔드에서 MV* 아키텍쳐란 무엇인가요?
Redux 핵심, Part 1: Redux Overview and Concepts
React Query와 함께 Concurrent UI Pattern을 도입하는 방법