Refactoring( Presentaional / Container Component )

📱 고민의 이유

요 근래 나만의 프로젝트를 만들면서 코드를 제작하다 보니 점점 너저분해지는 감각을 버릴 수가 없었다.

심지어 원래 import되어서 오는 컴포넌트와 내부 컴포넌트를 구분하고 Media query를 컴포넌트별로 독립적으로 관리하도록 만드려고 했던 구조가 점점 값을 참조하기 어렵고 복잡해지며 깊이가 깊어지는 형태가 되는 것을 벗어날 수가 없었다

이는 분명히 나중에 유지보수적으로 문제가 될 것이 자명했다.
그래서 리펙토링을 하기로 마음먹었다.

📱 문제의 확인절차

일단, Refactoring의 앞서, S의 형태로 현재 컴포넌트 내에서 정의된 styled component와 외부에서 가져와지는 styled component를 구분하는 것,

그리고 media query를 따로 외곽에 설정하여 빠르게 참조할 수 있는 구조에 대해서 생각을 다시 해보았다.

styled component는 컴포넌트 내에 S 객체에 모두 한번에 저장중이고

media query는 바로 하단에 위치하여 break point별로 S객체에서 타게팅할 styled-component를 가져와서 스타일조정하도록 만들었다.

해당 구조에 대해서는 초반에 작성하는게 귀찮을 뿐 참조하기가 쉽다는 점에서는 계속 유지하는 것이 맞아보였다.
(이전, 모든 컴포넌트별로 media query를 따로 두면서 정말 찾기가 힘들었던 것을 감안하면 상당히 괜찮은 방법이었다.)

그렇다면,
이제 가장 문제가 되었던 것은 아무렇게나 중구난방하게 한 컴포넌트 파일에 전부 작성되어 난잡한 상태인 컴포넌트를 분리하여 정리할 필요가 있었다.

작성방식에 대해서 고민하던 도중, Presentaional Component와 Container Component 개념을 알게 되었다.

📱 Presentational Component vs Container Component

표현형 컴포넌트와, 컨테이너 컴포넌트의 개념은 코드를 작성하는 디자인 패턴 중 하나이다.

컴포넌트를 분리할 때에 어떤 기준으로 분리할 것인가를 규정한 것으로서, 이때의 기준은

"컴포넌트가 UI적인 기능만 담당하는가 아니면 데이터 처리와 함께 데이터를 전달하는 역할을 하는가"

이다. 이를 표로 나타내면 다음과 같다.

물론 방법론이기 때문에 반드시 지켜야한다는 것은 아니지만,
이제까지 컴포넌트를 아예 분리하지 않거나 이상한 기준으로 분리하던 나에게 있어 아주 합리적인 형태로 보였다.

또한, Container Component와 Presentational Component가 하는 일이 비교적 뚜렷하기 때문에 유지보수를 할 때에도 어떤 문제로 추적해야할지 명확하니 훨씬 좋아보였다.

따라서, 해당 기준으로 컴포넌트를 분리하고 아래와 같은 룰을 적용하기로 하였다.

📱 적용 규칙

1. 한 route page에서 보여지는 컴포넌트가 Presentaional Component라면 이름 뒤에 PC라고 붙이고, PC 폴더에서 모아서 한번에 관리한다.

2. 컴포넌트가 Container Component라면 이름 뒤에 CC라고 붙인다.

위와 같이 한 이유는, 나중에 에러가 발생했을 때 콘솔에 찍히는 파일의 이름으로 최대한 빠르게 오류가 난 부분을 추적하기 위함이다. 뒤에 CC인지 PC인지 붙어있기 때문에 어디에서 일어난 오류인지 인지 짐작하기 쉽다.

3. PC는 props를 통해 내려지는 정보를 가지고 UI를 만들며, 내려받는 함수를 통해서만 hydration을 진행하여 상호작용을 만든다. 데이터를 조금이라도 가공하면서, 해당 데이터가 컴포넌트와 그 하위 자식들에게 독립적일 경우 CC로 분리한다.

단 위 방식에 대해서는 조금 염려되는 부분이 있다. 이렇게 제작할 경우 필연적으로 PC가 많아지면 그만큼 CC에서 처리하게 되는 내용이 점점 비대해지게 된다. 하지만 이건 어쩔 수 없는 trade-off라고 생각된다. 그렇기 떄문에 가장 최외곽의 CC가 모든 통신처리를 담당하는 것이 아니라, 오롯이 로직처리가 그 컴포넌트 기준 하위 레벨에만 적용되고 부모나 형제에게 적용될 필요가 없다면 CC로 분리하는 것이다.

모든 컴포넌트에서 전역적으로 활용되야 한다면, redux에 의하여 데이터가 관리되며 CC에 의해 조회되어 처리되고 PC로 전달한다.

📱 적용 결과

파일을 모두 일괄적으로 정리하여 PC는 따로 분리하였다.
한 route page 내에서 명확하게 presention만 담당하는 컴포넌트를 독립적으로 분류한다.

결과적으로 아래와 같이 한도끝도없이 광활하게 펼쳐져있던 수많은 요소들의 내용들이

아래와 같이 일괄적인 기준에 따라 깔끔하게 정돈된 것을 볼 수 있었다.