본문 바로가기

DEV/디자인패턴

[디자인패턴] container-presenter 디자인 패턴(컨테이너, 프리젠터)

thumbnail

 

오늘은  container-presenter 패턴에 대해서 조금 써볼까 합니다.
container-presenter 패턴은 처음 코딩을 시작하던 때 부트캠프에서도 사용하던 패턴이고
지금도 아토믹과 함께 업무, 개인 프로젝트에 적용하여 사용하고 있는 패턴입니다.

 

기존에 atomic구조를 공부하면서 간단하게 올렸던 글이 있는데 이 글도 같이 봐주시면 감사하겠습니다 🙇‍♂️🙇‍♂️🙇‍♂️

 

[디자인 패턴] atomic과 container,presenter

요즘 개인적으로 사이드 프로젝트를 진행하는데 있어서 디자인패턴에 대한 고민이 생겼다. 기존 내가 사용하던 패턴은 코드캠프에서 배웠던 container-presenter 패턴이었지만, 최근 추세와는 조금

takd.tistory.com

 

container-presenter pattern?

container(컨테이너), presenter(프리젠터)를 사용해 로직과 마크업을 이용한 UI를 분리하여 사용하는 디자인 패턴입니다.

로직과 마크업이 분리되어 있기에 기능과, UI의 코드 구분이 쉬워지는 장점이 있습니다.

코드의 구분이 쉬워짐에 따라 유지보수에 있어서도 이점이 있고, 재사용성이 뛰어나며 마크업 변경에도 유연한 구조를 가지게 됩니다.

 

container

컨테이너는 로직적인 부분을 작성 및 관리하며 컨터이너 내부에서 state 조작하게 됩니다.

데이터와 데이터 조작에 관련된 함수를 만들어 props로 프리젠터에 넘겨줍니다.

 

아래는 프로젝트 초기 세팅을 마친 프로젝트의 예시 코드입니다.

위의 사진에서 보이듯 Container에서는 마크업을 별도로 이용하지 않고 프리젠터만 임포트하여 랜더링 해줍니다. 

 

presenter 

프리젠터는 사용자에게 보여줄 UI를 작업하는 컴포넌트라고 생각하면 간단합니다.

state를 직접적으로 조작하지 않으며 위에 설명된 내용처럼 컨테이너의 props를 받아 state를 변경하게 됩니다.

상태를 가지지 않으며 만일 상태가 존재하게 된다면 그 상태는 UI의 상태가 되어야합니다. 

 

아래는 프로젝트 초기 세팅을 마친 프로젝트의 예시 코드입니다.

이 사진을 보면 UI를 프리젠터에서 그리고 있습니다.

 

container-presenter 패턴의 장/단점?

장점

- 로직과 UI를 구현하는 부분이 명확하게 나뉘어 코드를 유지/보수 하기에 좋다. 

- 재사용성이 극대화 될수 있다. 

 

단점

- 파일의 갯수가 많아질수 있다. 

- props가 많아지면 파악하기에 어려울수 있다. 

 

지금 당장 생각나는건 이정도가 있는데 혹시 더 있으면 댓글 부탁드립니다! 저도 사용하면서 추가하도록 하겠습니다. 

 

반응형