컴포넌트 분리하는 기준과 방법 요약

원본 블로그 링크 : https://medium.com/@shinbaek89/프론트엔드-아키텍처-컴포넌트를-분리하는-기준과-방법-e7cf16bb157a

컴포넌트란?

컴포넌트는 프로그래밍 언어 수준이 아닌 소프트웨어 디자인 수준에서 나눌 수 있는 가장 작은 단위이다.

언제 나눠야 하나?

주로 재사용성과 복잡성을 기준으로 많이 고려한다.

재사용 가능한 컴포넌트

재사용 가능하다는 것은 일반적이라는 것이다.

우리는 컴포넌트의 재사용성을 고려할 때 ‘다른 컴포넌트가 가져갈서 사용할 수 있도록 보편적인 속성을 갖고 있는가?’를 고민한다. 컴포넌트는 벤다이어그램에서 교집합 부분을 만들어야 한다.

중복을 제거하기 위해 컴포넌트를 분리한다. 시간이 지나면 그 컴포넌트가 점점 거대해지고 안에 조건문이 생기는데, 이는 상위 컴포넌트와 하위 컴포넌트간 강한 결합이 생겼기 때문이다. 강한 결합은 변경이 더 어렵다는 걸 의미한다.

이 상황의 다른 문제는 의존성이다. 분리한 컴포넌트를 수정하면 사용하고 있는 페이지가 영향을 받기 때문에 문제가 발생하지 않는지 살펴봐야 한다.

이러한 문제는 왜 발생하는가? 가장 먼저 컴포넌트가 반환하는 요소의 중복을 추출해서 재사용하는 접근 방법이 문제의 발단일 수 있다. 중복 제거와 관련된 DRY원칙은 중복을 겉모습으로 판단하지 않는다. 만약 모습이 같은 두 코드가 같은 이유로 수정되어야 그 코드는 중복이다. 같은 모습의 코드라도 수정의 이유가 다르면 중복이 아니다.

조건문이 없는 컴포넌트를 만들기는 어렵다. 단, 조건문을 추가할 때 컴포넌트의 관계에 어떤 영향을 주는지 이해할 필요가 있다.

의존성 문제는 재사용하려는 컴포넌트에 정말 공통적인 것만 남겨두고 사용하는 컴포넌트의 고유한 것은 속성으로 전달하는 방식으로 해결할 수 있다. [참고]

복잡한 컴포넌트

컴포넌트를 나누는 중요한 또 다른 이유는 컴포넌트의 복잡성 때문이다. 컴포넌트가 복잡해지는 이유는 여러가지가 있다.

그 중 하나는 컴포넌트가 여러 책임을 갖는 경우이다. 여러 책임을 갖는 컴포넌트는 컴포넌트 분리 없이 만든 거대한 페이지 컴포넌트와 비슷하다. 이렇게 되면 기능 간에 결합이 강하게 발생해서 수정이 쉽지 않다.

그렇기 때문에 컴포넌트를 책임에 맞게 나눠서 문제를 단순화 해야 한다. 페이지 컴포넌트가 모든 정보를 취합해 컨텐츠를 보여주는 등 모든 책임을 갖지 않도록 한다. 그리고 분리를 통해 페이지 컴포넌트에 모두 모여있으면 발생할 수 있는 다른 컴포넌트와의 직접적인 상호작용을 제거하거나 차단한다.

이 방법은 캡슐화라고 할 수 있다. 여러 책임이 한 곳에 모여있으면 각 컴포넌트가 서로 강하게 결합될 가능성이 높다. 컴포넌트가 자신의 책임을 갖도록 분리하고 다른 컴포넌트와 상호작용 할 땐 정해진 방법으로 하는게 좋다. 즉, 스스로와 관련된 변겨은 각 컴포넌트가 책임짐으로써 감추고, 잘 변경되지 않는 외부와의 메시징은 제한하는 캡슐화는 컴포넌트를 관리하는 좋은 방법이다.

그리고 컴포넌트 내부에 비즈니스 로직이 있는 경우도 컴포넌트를 복잡하게 만든다. 일반적으로 유저 인터페이스와 비즈니스 로직은 변경의 빈도가 다르다. 비즈니스 로직은 자주 변경되지 않는다. 하지만 컴포넌트에 비즈니스 로직이 포함된다면 빈번한 ui 변경에 자주 영향을 받을 수 있다. 따라서 ui 와 비즈니스 로직을 적절하게 분리해야 한다.

렌더링 퍼포먼스의 이유로 컴포넌트를 분리하는 경우도 있다.