리액트에서 과거에 자주 언급되고 활용되었던 패턴중 Presentational and container components 라는 패턴이 있다.
왜 이런 패턴을 사용했는가
리액트의 컴포넌트는 상태,DOM , 이벤트 등을 모두 관리할수 있다.
이는 리액트 의 생태계에서 자유롭게 컴포넌트를 활용할 수 있다는 의미이지만 컴포넌트 간의 의존도가 높아지는 것을 경계하지 않는다면 추후 어플리케이션이 비대해졌을때
코드의 재사용이 불가능해진다.
그래서 컴포넌트 내에세도 추가적으로 레이어를 적절히 나눠 의존도를 낮춰주어야 할 필요를 느꼈고 Hook 의 개념이 존재하지 않았던 이전에 로직과 view 를 분리하기 위한 방법으로 등장한 것이 presentational and container 패턴이다.
presentational 컴포넌트
- html, css, presentational component만 사용 가능하다.
- app에 대해 완전히 몰라야한다. => 다른 app에서도 이 component를 사용할 수 있을지 스스로에게 물어보자
3.presentational과 container 모두를 내부적으로 가질 수 있다.
4.작은 레고 블럭처럼 가능한 작게 만들어야 한다.
5.상태를 가질 수 있지만 UI에 관련된 상태만 가질 수 있다.
6.필요 시 visual을 바꾸는 props를 받을 수 있어야 한다.
7.가끔 완전히 다른 스타일을 불러오는 props를 받기도 한다.
container 컴포넌트
1.어떠한 동작을 할 것인가 대해 책임진다.
2.절대로 DOM 마크업 구조나 스타일을 가져서는 안된다.
3.presentational과 container 모두를 내부적으로 가질수있다.
4.주로 상태를 가지고 있다.
5.side effects 를 만들수있다.
6.props 를 자유롭게 받을수 있다.
🙋 해당 패턴을 도입하여 얻을수 있는 이점은?
1.재사용성을 높일 수 있다.
로직이 포함되어 있지 않은 presentational 컴포넌트는 그저 받아온 정보를 화면에 표현할 뿐이므로 presentational 컴포넌트가 다른 컴포넌트를 알 필요가 없다는 점에서 의존도가 낮아 다양한 container 컴포넌트와 조합하여 재사용 할수 있다는 장점 .
- 구조에 대한 이해가 쉬워진다. 기능과 UI가 명확히 분리되므로 개발자 입장에서 코드 구조에 대한 이해가 쉬워진다.
3.마크업 작업이 편하다.
presentational 컴포넌트는 layout 컴포넌트로 활용하여 반복되는 마크업 작업을 줄여줄수있다.
presentational 과 container를 나누는 기준
대체적으로 presentational 컴포넌트는 stateless 한 경향이 있고 container 컴포넌트는 stateful 한 경향이 있다.
하지만 이것은 presentational 과 container 를 나누는 절대적인 기준이 아니므로 컴포넌트를 나눌때는 state를 가지고 있냐 없냐 같은 기능적인 부분에 집중하지 말고 해당 컴포넌트가 어떤 목적을 가지고 있는지에 집중하는것이 좋다.
