Frontend/React

[React] 컴포넌트에 대한 고찰

sol_git 2024. 12. 18. 10:00

✨ React 에서의 Component

1. 컴포넌트란?

  • 소프트웨어 디자인 수준에서 나눌 수 있는 가장 작은 단위로, 재사용이 가능한 각각의 독립된 모듈을 뜻 함.
  • 프론트엔드에 적용하자면, `웹·앱을 구성하는 가장 작은 단위`

 

2. 컴포넌트화를 해야 하는 이유는 뭘까?

컴포넌트 방식(파일을 여러개로 쪼개서 관리하는)을 사용하는 목적은 바로

1. 유지 보수의 용이성
2. 성능 개선

이 두 가지의 목적이 가장 크다.

하나의 스크립트만으로 코드를 작성이 불가능한 것은 아니다.
그러나, 프로젝트의 기능이 다양한 경우, 한 기능을 수정하기 위해 코드를 다 뒤져야 하는 상황이 발생한다.
컴포넌트화가 되어있다면, 수정할 기능이 있는 컴포넌트 파일로 바로 찾아가서 수정하면 된다!

즉, 컴포넌트화 하게 된다면!

  • 메인 어플리케이션과 완전히 분리되어, 재사용성, 테스트 가용성, 신뢰성이 높아짐
    • 컴포넌트가 내부 동작에만 반응할 뿐, 메인 어플리케이션의 상태에는 관여하지 않기 때문
      • 컴포넌트 업그레이드 시, 어플리케이션의 나머지 부분에 영향을 미칠 지 걱정하지 않아도 됨
    • 컴포넌트화가 되어있는 경우, 개발자가 이미 있는 기능을 가져다가 다시 사용하기 쉬워짐

 

3. 그렇다면, 컴포넌트를 나누는 기준은 뭘까?

기준에 정답은 없지만, 보편적으로 많이 선택되는 기준은 바로 `재사용성`, `복잡성`이다.

코드가 재사용 될 가능성이 있다면, 새로운 컴포넌트를 만드는 것이 좋다.
코드가 복잡하다면 가독성을 개선하고 쉽게 유지보수 하도록 컴포넌트를 분리하는 것이 좋다.

 

그러나, 컴포넌트를 만들 때, 가장 많이 발생하는 실수가 있었으니..

1. 복잡한 컴포넌트를 만드는 경우
2. 하나의 컴포넌트에 여러 책임을 지게 하는 경우
3. 몇몇 동작하는 부분을 결합하여 컴포넌트를 만드는 경우
4. 비즈니스 로직을 컴포넌트에 추가하는 경우

(출처 : 프론트엔드 아키텍처)

 

4. 컴포넌트 기준을 조금 더 자세히 알아보자

ⓐ 하나의 컴포넌트에 여러 책임을 지게 하는 경우

  •  기능 간 결합이 강하게 발생해서, 유지보수가 어려워진다.

이를 해결하기 위해서는, 컴포넌트의 책임을 나눠야 한다.

각 컴포넌트는 각자의 UI에 대한 책임(B)만 갖게 되며, 컨텐츠 컴포넌트와의 소통은 A를 통해서만 이뤄짐. 다른 컴포넌트와의 직접적인 상호작용(C)은 제거하거나 차단해야 함

  •  잘 만들어진 컴포넌트의 예시)

A, B로만 로직이 이루어져있고, 그 중에 A는 최소화 시킴

 

ⓑ 비즈니스 로직을 컴포넌트에 추가하는 경우

일반적으로, UI와 비즈니스 로직은 변경의 빈도가 다름(UI의 변경의 빈도가 잦고, 비즈니스 로직은 UI에 비해 변경이 적은 편)

그러나, 컴포넌트에 비즈니스 로직이 포함된다면? UI 변경에 따라 자주 영향을 받게 될 수도 있다!

컴포넌트에 비즈니스 로직이 아예 포함이 되지 않을 수는 없겠지만, 적절히 분리하는 것도 소프트웨어의 유지보수에 아주 중요함

이와 관련된 추가 내용은 이 글을 참고해보시길.. (아직 넘 어렵 ㅠ)