개인 프로젝트를 진행하다보니 점점 컴포넌트가 많아지고 서로 의존하는 컴포넌트가 많아지다보니 이게 맞는 개발 방법인가?에 대한 의문이 생기기 시작했다.

일단 아는 지인분께도 여쭤보고 이것저것 자료를 찾아보기 시작했다. 리팩토링을 하기 전에 프론트엔드 개발을 하면서 한번 씩은 고민해볼만한 컴포넌트에 관해서 정리해보려한다.

컴포넌트란 뭘까?

생각해보니 지금까지 공부를 하면서 컴포넌트에 대한 정확한 정의에 대해서 생각하지 않았던 것 같다. 그냥 HTML 요소를 담고 있는 조각 정도로만 생각했다.

컴포넌트는 재사용 가능한 부분을 구성하는 독립적인 요소다.

컴포넌트는 애플리케이션의 작은 부분을 캡슐화하고, 이를 조합하여 복잡한 기능을 구현하는 데 사용된다. 컴포넌트 기반 개발은 코드의 재사용성, 유지 보수성, 가독성을 향상시킨다.

컴포넌트는 UI를 구성하는데 사용되며, 버튼, 입력 폼, 메뉴, 헤더, 푸터 등 각각의 UI 요소를 컴포넌트로 분리하여 개발할 수 있다.

컴포넌트는 일반적으로 다음과 같은 특징을 가지고 있다.

1. 재사용성: 컴포넌트는 독립적으로 동작하며, 다른 부분에서도 재사용될 수 있다. 이로써 코드의 중복을 줄이고 효율적인 개발을 가능하게 한다.

2. 독립성: 각 컴포넌트는 자체적으로 상태와 동작을 관리한다. 다른 컴포넌트와 독립적으로 동작하므로, 한 컴포넌트의 수정이 다른 컴포넌트에 영향을 미치지 않는다.

3. 추상화: 컴포넌트는 UI 요소를 추상화하여 사용자에게 필요한 기능을 제공한다. 이로써 복잡한 기능을 간단하게 구현할 수 있고, 유지 보수와 확장이 용이해진다.

잠깐만 독립성?

여기서 독립성에 대해서 의문이 들었는데, props로 전달받은 컴포넌트는 props를 전달해주는 컴포넌트가 수정된다면 충분히 영향을 미칠 수 있는 것 아닌가?

당신의 컴포넌트는 안녕하신가요

이 글에서 설명하기로는 위 세 가지 특징은 컴포넌트의 최대 목표를 의미하는 말이 아닐까? 라고 한다. 나도 이 말이 맞다고 생각한다. 아무래도 의존성을 아예 없애버리는 것은 불가능하다고 생각하기 때문이다.

컴포넌트의 역할

이전에 퍼블리셔 업무를 했을 때 무언가 감싸는 최상위 DOM 요소에 container 라는 클래스명을 주고 관리했던 기억이 난다.

컴포넌트 또한 각자 역할을 구분해서 사용하는 것이 효율적일 것이다.

Presentational 컴포넌트와 Container 컴포넌트

Presentational 컴포넌트

Presentational 컴포넌트는 View만을 담당하는 컴포넌트다.

이 컴포넌트는 DOM 요소와 스타일만을 가지고 있어야 하고, Presentational 컴포넌트나 Container 컴포넌트를 가지고 있을 수도 있다.

하지만 리덕스와 같은 상태 관리에 직접적인 접근 권한이 없고 오직 props 로만 데이터를 가져올 수 있다고 한다.

또한, 대부분의 경우 state를 갖고 있지 않아야 한다. 만약 state를 갖게되는 경우에는 데이터에 관련된 state가 아니라 UI에 관련된 state여야 한다.

간단하게 정리해보자면

• DOM 요소와 컴포넌트, 스타일만을 가지고 있어야 한다.
• 상태 관리에 직접적인 접근 권한이 없다.
• 데이터는 props로 전달받아서 사용한다.
• state는 UI에 관련된 state만 가져야 한다.

Container 컴포넌트

Container 컴포넌트는 Presentational 컴포넌트와 Container 컴포넌트들을 관리하는 것을 담당한다.

주로 내부에 DOM 요소가 직접적으로 사용되는 경우가 없다. 만약 사용되더라도 감싸는 용도로 사용한다.

또한, 스타일을 가지고 있지 않아야 한다. 상태를 가지고 있을 때가 많으며, 리덕스와 같은 상태 관리에 직접적으로 접근할 수 있다.

간단하게 정리해보자면

• 컴포넌트들을 관리하는 담당이다.
• DOM 요소는 감싸는 용도로만 사용한다.
• 스타일을 가지고 있지 않아야 한다.
• 상태를 가지거나 상태 관리에 직접적으로 접근할 수 있다.

어떤걸 Container로 만들어야 할까?

위 글에서는 아래와 같은 경우에 Container로 만들어야 한다고 한다.

• 페이지

• 리스트

• 헤더

• 사이드바

• 내부의 컴포넌트 때문에 props가 여러 컴포넌트를 거쳐야 하는 경우

컴포넌트는 언제 나눠야 할까?

이제 본격적으로 어떤 경우에 컴포넌트를 나눠야 하는지 내가 지금 잔뜩 만들어 놓은 컴포넌트들이 계속 존재해도 괜찮은지 알아보자.

컴포넌트를 만드는 기준 중 가장 많이 선택되는 이유는 재사용성과 복잡성이다.

코드가 재사용될 가능성이 있다면 새로운 컴포넌트를 만드는 건 좋은 생각이다. 코드가 복잡하다면 가독성을 개선하고 유지보수 할 수 있게 만들기 위해 컴포넌트를 분리할 수 있다.

컴포넌트를 만들 때 가장 많이 발생하는 실수

1. 복잡한 컴포넌트를 만든다.

2. 하나의 컴포넌트에 여러 책임을 추가한다.

3. 몇몇 동작하는 부분을 결합하여 컴포넌트를 만든다.

4. 비지니스 로직을 컴포넌트에 추가한다.

프론트엔드 아키텍처: 컴포넌트를 분리하는 기준과 방법

이 글을 정독한다면 컴포넌트를 분리하는 기준을 정하는 데 도움이 된다.
이 글에 대해서 정리한다면 그냥 복붙만 하는 기분이라 그냥 링크를 첨부한다.

컴포넌트를 분리하는 기준과 방법은 아래와 같다.

• 재사용 가능한 컴포넌트

  • HTML 요소 측면에서의 재사용성
  • 중복을 고려한 재사용성

• 복잡한 컴포넌트

  • 컴포넌트가 여러 책임을 갖는 경우
  • 컴포넌트에 비지니스 로직이 있는 경우

• 렌더링 퍼포먼스

당장 리팩토링하고 싶어서 참을 수가 없다. 곧 밤 12시이기 때문에 얼른 자고 일어나서 리팩토링을 시작해야 겠다.😤

참고
변경에 유연한 컴포넌트