컴포넌트... 어떻게 나눠야 할까?

아래 포스팅 기반으로 정리된 글입니다..! 이 글은 개인 정리이니 아래 글을 참고해주세요

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

쓰레기같은 나의 코드.... 이제 리팩토링으로.. .R.I.P.

FrontEnd는 그저 화면싸개...? 

처음엔 화면만 예쁘게 만들면 되지 않을까? 하고 생각했었는데 오히려 프론트 엔드는 공부할 수록 어려워지는 것 같다. 

 

물론 백도 그렇겠지..?

일단 새로운 라이브러리가 너무 많이 나오고 생각보다 회의로 정해야하는 것이 너무 많다는 것... 

또, 재사용성 유지 보수성 확장성.... 이런걸 고려하라고 하는데 정확한 기준은 없고 이렇게하면 좋더라~ 저렇게하면 좋더라~ 근데 아닐 수도 있으니 잘 사용해야한다~ 하는 이야기들이 넘 많음. 

 

그동안 이런 저런 글도 찾아보고 아토믹 디자인 방법론... 등등... 여러가지 글을 봤었는데 

이번에 한 번 정리해보고 어떤게 좋을지 생각해보기로 했다! (리팩토링 할 거니깐~!)

 

---

컴포넌트 분리... 왜 해야할까? 

1. 향상된 코드 유지보수성 

컴포넌트 분리를 위한 가장 설득력 있는 주장이다. 

개발자들이 기능을 별개의 컴포넌트로 분리함으로써 애플리케이션의 한 부분에서의 변경이 의도치 않게 다른 부분에 영향을 미치지 않도록 한다. 

이러한 분리는 업데이트와 디버깅을 단순화 한다.

 

2. 더 쉬운 테스팅

컴포넌트 분리는 본질적으로 테스팅 과정을 단순화한다. 더 작고 잘 정의된 컴포넌트는 개별 기능에 초점을 맞춰 독립적으로 테스트될 수 있어 애플리케이션의 신뢰성을 향상시킨다.

-> React Test Library는 컴포넌트 기반의 테스트를 한다!

 

3. 향상된 확장성

애플리케이션이 성장함에 따라 확장 가능한 구조를 유지하는 것이 점점 더 힘들어진다. 컴포넌트 분리는 모듈식 아키텍처를 장려함으로써 확장을 용이하게 만들고 쉽게 재사용되고 적응될 수 있어. 다시 발명 없이 새로운 기능을 개발하도록 한다.

 

4. 용이한 팀 협업

컴포넌트 분리는 자연스럽게 팀이 탐색하고 협업하기 쉬운 코드베이스로 이어진다. 컴포넌트가 명확하게 정의되고 분리되어 있을 때 개발자가 애플리케이션의 다른 부분에서 동시에 작업할 수 있으며 서로의 작업에 방해가 되지 않는다. 이 관심사의 분리는 새 팀원이 애플리케이션 구조를 빠르게 이해하는 데도 도움이 된다.

 

---

 

예전에는 Presentational Components와 Container Components라는 분리 방법이 있었다고 하는데, 이 방식은 React가 class형 컴포넌트를 던지고 function 형으로 바뀌면서 던져진 듯 하다. 저자가 더 이상 쓰지 말라네...

https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0

 

언제 나눠야 할까?

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

 

컴포넌트를 만들 때 가장 많이 발생하는 실수 다섯가지 
1. 복잡한 컴포넌트를 만든다 
2. 하나의 컴포넌트에 여러 책임을 추가한다. 
3. 몇몇 동작하는 부분을 결합해 컴포넌트를 만든다
4. 비지니스 로직을 컴포넌트에 추가한다.

 

A. 재사용 가능한 컴포넌트 

A-1 재사용 가능하다는 것은 일반적이라는 것이다. -> 보편적이라는 것이다 

** 컴포넌트의 재사용성을 고려할 때 일반적이라는 두 가지 측면 중 '속성이 보편적'인지 고민한다. 즉, '다른 컴포넌트가 가져가서 사용할 수 있도록 보편적인 속성을 갖고 있는가?'를 고려한다. 마치 아래 그림에서 빨간색으로 칠해진 부분을 만들어야 한다는 것...

A-2 HTML 요소 측면에서의 재사용성

-> li 요소를 블록으로 간주하지 말자. (BEM 개념을 참고해라)

 

A-3 중복을 고려한 재사용성

컴포넌트의 재사용성에 대해 말할 땐 보통 중복을 떠올린다. 두 곳 이상에서 중복된 무언가 존재하고 '추출' 하는 과정을 거친다. 그리고 재사용한다....

중복 되지만... 조건문이 들어가기도 한다 >> 조금씩 다르기 때문에 

=> 이런 경우 의존성 문제가 발생한다. 컴포넌트가 점점.. 거대해지고 .. 결합이 거대해짐!!

 

왜???  요소의 중복을 추출해서 재사용해야 한다는 접근 방법이 문제의 발단일 수 있습니다. 

조건문이 안들어가기는 솔직히.. 어렵다. 그래도 이런 문제가 발생한다는 거랑, 어떻게 영향을 주는지 알아놔야한다. 

너무 의존적인 컴포넌트는 다른 걸 수정하려다 이상한게 수정될 수도 있다.... 내가 이렇게 많이 짜놨...

 

A ? 그럼 어떻게 해야할까?

- 재사용하려는 컴포넌트에는 정말 공통적인 것들만 남겨두고 사용하는 컴포넌트의 고유한 것은 속성으로 전달하자.

 

React 공식문서에서도 추천함

 

B. 복잡한 컴포넌트

컴포넌트의 복잡성을 이유로 나누기도 한다. 복잡해지는 이유는 다음과 같다. 

 

B-1. 컴포넌트가 여러 책임을 갖는 경우

아아.. 단일 책임 원칙...SRP....SOLID...를 기억해라... 하나의 함수는 하나의 일만!! 

 

각 컴포넌트는 각자의 UI에 대한 책임(B)를 갖는다. 그리고 컨텐츠 컴포넌트와의 소통은 A라는 경로를 통해서만 이루어진다. 

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

 

B-2. 컴포넌트에 비지니스 로직이 있는 경우

일반적으로 유저 인터페이스(UI)와 비지니스 로직은 변경의 속도, 즉 빈도가 다르다. 예를 들어, 상품 카드에 환불이 가능한지 표시하는 방법은 많고 수시로 바뀔 수 있다... 빨간색이었다가..회색이었다가...

근데, 환불 가능 조건을 변경하는 건 사업 초기에 한 번 정해지고 안 바뀔 수 있다.

 

하지만 컴포넌트에 비지니스 로직이 포함된다면..? 빈번한 UI 변경에 따라 자주 영향을 받음

 

 

프로젝트를 할 때도 컴포넌트 분리에 대한 고민을 많이 해 왔다. 근데 다시 코드를 열어보니까 의존성이 ㅋㅋ..개판...

 

C. 렌더링 퍼포먼스

재사용, 복잡성 외에 좋은 기준은 렌더링 퍼포먼스다. 하나의 컴포넌트 안에서 서로 영향을 주지 않는 상태가 여럿 있으면 발생하는 문제다. 이건 내가 많이 썼었지 ㅇㅇ.. 이번에 하면서 다 잡아버리겠어.

 

---

 

 

[강추!]

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

[비즈니스 로직과 View의 분리 : 컴포넌트]

프론트엔드 아키텍처: Business Logic의 분리

[컴포넌트 분리의 중요성]

[React] 컴포넌트 분리의 중요성

[강추!]

 

React 컴포넌트와 추상화 | 카카오엔터테인먼트 FE 기술블로그

[강추!]

합성 컴포넌트로 재사용성 극대화하기 | 카카오엔터테인먼트 FE 기술블로그