Next.js에서 Container-Presenter? 디자인패턴의 대한 고민

저는 가장 관심있어 하는 부분 중 하나가 프로젝트를 밑바닥부터 쌓아 올릴 때, 이 프로젝트를 어떻게 빌드업 해나갈 것인가?

 

즉, 설계에 대한 부분에 큰 관심이 있습니다. 클라이언트단에 어떠한 요구사항이 들어와도 처리할 수 있는 능력과 프로젝트 설계 능력을 가장 중점적으로 생각하고 있습니다.

 

제가 처음 입사해서, 프로젝트를 맞이했을 때와 현재 시점에서 프로젝트를 볼 때 관점의 차이가 생기는 것 같습니다.

 

다들 프로젝트의 디자인패턴은 어떤 걸 사용하시나요?

 

처음 프로젝트를 맞이했을 때, 저희 프로젝트는 가장 기본적인 디자인 패턴 Container, Presenter패턴을 사용하고 있었습니다.

 

Container에서는 비즈니스 로직과 관련된 코드, Api를 수행하고 state를 조작해서 props로 Presenter에게 넘겨줍니다. Presenter에서는 사용자가 직접 보고, 조작하는 컴포넌트로서 Container에서 넘어온 props를 가지고 View를 구성합니다.

 

 

즉, 기본 컨셉은 데이터처리와 출력을 구분하는 것입니다.

 

근데 여기서 불편한 것들이 존재하는데..

 

첫 번째로는 파일이 너무 많았습니다. 프로젝트가 큰 규모가 아님에도 불구하고 파일이 너무 많아 생기는 불편함이 있었습니다.

 

// components
import Presenter from "./Presenter";

const Container = () => {
  return <Presenter></Presenter>;
};

export default Container;

container presenter 패턴의 대한 불편함

이런식의 컴포넌트들도 많았기 때문에 이런 것들이 파일이 많아지는 것과 굳이 필요한가에 대한 의문점이 들었습니다.

 

두 번째로 Depth가 너무 깊어지는 불편함이 있었습니다. 다른말로는 props Driling이라고도 하죠. (데이터를 보내는 것의 대한 중복)

 

저희 프로젝트는 Next.js를 사용하고 있고, next는 pages 폴더로부터 자동으로 routing을 해주고 있는데 이렇게 되면 depth가 너무 깊어지는 현상이 발생합니다. pages -> container -> presenter 여기서 추가적으로 컴포넌트를 나누게 된다면 더 깊어질 수도 있습니다.

 

이렇게 depth가 깊어짐에 따라 props를 계속 내려줘야 되는 불편함이 발생하고, 내려준 props가 어디서부터 넘어왔는지 올라가고 올라가고 더불어 결합도도 높아지는 문제점이 발생하기 시작했습니다.

 

세 번째로 아무 생각 없이 부모에서 내려온 props를 받아쓰는 컴포넌트 (Dumb Conponent)가 많았습니다.

 

그래서 몇 가지 레퍼런스를 찾아봤습니다.

 

많은 정보들이 있었지만 결론적으로 Container - Presenter 패턴을 처음 소개했던 저자는 이 패턴을 추천하지 않았습니다.

Hooks가 나오기 전엔 기존 복잡한 상태 저장 논리를 구성 요소의 다른 측면과 분리할 수 있었기 때문이였는데,

Hooks가 도입되면서 임의의 분할없이 동일 작업을 수행할 수 있고, 함수형 컴포넌트로 작성함에 따라 Local state를 유연하게 처리할 수 있기 때문이였습니다.

 

그리고 Nextjs github로 갔습니다. 

pages에서 넘어가는 파일을 어떻게 구성하는지 간단하게나마 예시를 참고하려고 갔는데 index.js에서 처리하는 것들을 종종 볼 수 있었습니다.

 

그래서 지금 pages에서 끝낼 수 있는 작업들은 바로 view로서의 역할도 같이 할 수 있게끔 파일을 분리하고 있습니다.

pages만으로 분리가 어려운 녀석들은 한번 더 분리하고 기존 Container + Presenter + index의 파일들은 합쳐서 하나의 파일로 구성하는 작업을 진행하고 있습니다. 물론 로직 자체들이 큰 녀석들은 더 세분화하여 컴포넌트들을 분리해야 하지만 기존보다 훨씬 더 효율적으로 관리할 수 있게끔 리팩터링을 완료하였습니다.

 

 

결론적으로 리팩터링을 진행하면서 줄인 파일수만 170개 이상이 됩니다. 

추가로 기존에 Container - Presenter 패턴으로 쓰고 있던 것들은 컴포넌트 자체로 파악이 가능하게 도메인 패턴으로 바꿨고, Props Drilling 문제들이 해결되어 필요한 컴포넌트에 찾아가기 수월하고 코드파악이 더 쉬워지는 장점이 있었습니다.

 

공식적으로 있는 디자인패턴은 아니지만 (굳이 따지자면 도메인 패턴) Customizing을 하면서 저희만의 방식을 찾아가고 있습니다. 유명한 아토믹 디자인 패턴도 있지만 분리 기준이 주관적이고, 디자인팀과 같이 의논해서 결정해나가야 하는데 현재 시점에서 그럴 수 없는 상황이기 때문에 고려 자체를 못했던 것 같습니다. 

 

그러나 아직 Container - Presenter 패턴을 많이 사용하는 것 같긴 합니다.

추천하지 않는다고 하여 무조건 바꾸기보단, 들어가는 리소스와 목적성 등을 모두 고려해야 할 것 같습니다.