리액트로 프론트엔드 개발을 하고 있다면 Presentational & Container 디자인 패턴에 대해 들어보셨을 것이라고 생각합니다.
그렇다면 왜 이런 디자인 패턴을 사용해야 하는지도 알고 계신가요? 오늘은 왜 사용하는지에 대해 이야기해 보려고 합니다.
Presentational & Container 디자인 패턴이란?
Presentational & Container 디자인 패턴은 모든 개발자의 영원한 숙명인 Controller와 View를 분리하여 "하나의 함수는 하나의 일만 해야 한다"는 단일 책임 원칙을 준수하고, 유지보수를 용이하게 하며 예상치 못한 에러를 방지하기 위해 고안된 패턴입니다. 이 패턴은 UI 로직과 비즈니스 로직을 명확히 분리함으로써 코드의 가독성과 재사용성을 높이고, 테스트를 더욱 용이하게 만듭니다.
Presentational 컴포넌트는 주로 UI 렌더링에 집중하고, Container 컴포넌트는 데이터 처리 및 상태 관리를 담당하여 각 컴포넌트가 자신의 역할에 충실하게 합니다.
Presentational & Container의 역할
Container Component
- State를 포함하며 Presentational Component 에게 Props로 전달해준다.
- State를 변경할 수 있는 함수를 포함하며 Presentational Component 에게 Props로 전달해준다.
Presentational
- Props를 통해 전달받은 State를 사용하여 사용자에게 UI를 제공한다.
- Props를 통해 전달받은 Callback 함수를 사용하여 사용자와 상호작용하며, 상태를 변경한다.
🙋🏻♂️ 왜 setState 함수를 직접 Props로 전달하지 않나요?
setState 함수를 직접 전달하면 편하게 Presentational 컴포넌트에서 사용할 수 있는건 사실입니다. 다만
- Presentational Component에서 비즈니스 로직을 구현해야한다.
- Presentational Component에서 예상치못한 setState 함수 사용으로 에러를 발생시킬 수 있다.
Presentational Component는 단순히 UI 만을 위해 사용하는 컴포넌트 입니다. 상위 컴포넌트에서 Props 로 전달된 데이터를 변경할 수 있는 setState 함수는 Presentational Component의 권한을 뛰어넘는 일입니다.
add 버튼 컴포넌트에 setState 함수를 props로 전달했다고 가정했을 때, add 버튼은 온전히 추가하는 로직만 할 수 있을까요?
실수라도 삭제, 수정 기능을 구현할 수 있게됩니다. 그것은 개발자의 개발 의도와는 다르게 작동할 수 있고, add 버튼의 권한을 뛰어넘는 행동이기 때문에 setState 함수를 직접적으로 전달해서는 안됩니다.마치 학생에게 선생님의 권한을 주는 것과 같기때문이죠.
장점
- 관심사의 분리로 주요 로직과 UI를 분리하고 가독성 및 유지보수에 용이하다.
- Presentational Component는 데이터 변경 없이 화면에 출력할 수 있으므로 앱의 여러 곳에서 다양한 목적으로 재사용할 수 있다.
- Presentational Component는 앱의 비즈니스 로직에 관여하지 않으므로 코드베이스에 대한 이해가 깊지 않은 개발자라도 유지보수가 가능하다.
- Presentational Component는 순수 함수로 구현되므로 Unit Test를 간단하게 수행할 수 있다.
