Presentational-Container 패턴과 Hook

Presentational-Container 패턴의 모든 것: Hooks로 대체할 수 있을까?

 

위 포스팅을 읽고 작성하는 이해를 담은 포스팅입니다.

 

Presentational-Container 패턴이란?

- Presentational Component : UI(렌더링, 스타일)만 담당하며 상태나 비즈니스 로직이 없습니다. props로 받은 데이터를 시각적으로 표현하는 역할만 하도록 해 재사용성과 테스트 용이성이 높아진다. (dumb component)

- Container Component : 상태 관리, API 호출, 이벤트 처리 등의 비즈니스 로직을 담당하며, 전달받은 데이터를 Presentational 컴포넌트로 넘깁니다.

 

장점

- 책임 분리 -> 가독성 유지보수성, 테스트 용이성을 향상시킴

- 대규모 어플리케이션에서 효과적이며, UI 개발자 / 로직 개발자 간 협업에 유리함

 

단점

- 프로젝트가 작을 경우 구조가 과해지고, 파일 수 / 폴더 구조의 복잡도가 올라감. 또한 props chain이 길어질 경우 전달 과정이 복잡해져 (Context, Props Drilling) 전달 과정이 번거로워질 수 있음.

 

Presentational-Container 패턴에 대한 이해

내가 이해하기로는 Presentational-Container 패턴은 MVC 패턴과 비슷한 면이 있다. View가 Presentational Component이고 Model, Container를 합친 것이 Container Component로 이루어진 것처럼 보인다.

 

그러나 MVC 구조는 View-Controller-Model-View 순환 구조를 가지고 있지만 React의 철학인 단방향 데이터 흐름에 따라서 Container Component -> Presentational Component 단방향 Props 전달이 이루어지는 것이 차이점인 것 같다.

 

Component를 로직과 뷰로 분리하기 때문에 관심사 분리와 재사용성 증가로 코드의 유지보수성과 컴포넌트의 일관성을 증가시키는 장점이 있지만 단점으로 지속적으로 이야기하는 부분이 복잡도 증가이다. 체계적인 관리가 없다면 구조적인 복잡도 때문에 오히려 생산성이나 유지보수성이 떨어질 수 있다. 해서, 대규모 어플리케이션에 적용해야 한다는 것을 지속적으로 강조하는 것이다.(오버 엔지니어링 주의)

 

그런데 이제는 Hook의 등장으로 안 쓴다? 

리액트의 Custom Hook으로 비즈니스 로직을 관리하는 경우가 많다. 이 경우에는 각각의 기능에 따라서 함수로 선언되고 UI와 완전히 분리되어 비즈니스 로직과 UI가 섞이지 않는다.

 

Custom Hook을 이용할 경우 각각의 Hook별로 SRP 또한 분리하기가 쉬워지므로 요즘에는 Hook을 이용하는 경우가 많다. 그럼에도 Presentational-Container 패턴을 사용해야 하는 이유가 있다.

 

- 복잡한 상태 관리를 위해 : 여러 Presentational Component가 동일한 상태를 공유하는 경우, 컨테이너 컴포넌트를 통해 상태를 집중적으로 관리해 로직을 모아 한번에 상태를 공유시킬 수 있다.

- 깊은 컴포넌트 계층 구조 : 중첩된 컴포넌트에서 비즈니스 로직을 상위에서 하위로 전달할 때 Container Component는 데이터를 한 곳에서 처리하고 props로 전달함으로써 구조를 명확하게 유지함.

- 분업화된 개발 환경 : UI 개발자와 로직 개발자가 분리된 경우 관심사를 완전히 분리할 수 있다.