컴포넌트 기능 관리에 대한 고찰

제목을 뭘로 지어야 할지 모르겠어서 대충 써봤다.
갑자기 생각났는데, 기존의 고민을 해결할 수 있을 것 같아 급하게 써본다.

---

다양한 기능을 가지는 최하위 UI 컴포넌트

기능 개발을 하다보면 UI 컴포넌트를 관리하게 된다.
제일 복잡한 데이터테이블 컴포넌트를 가져와보자

이해를 돕기 위해 props의 설명을 써두겠다.

columns: 컬럼 정보. 타이틀, 색상, 정렬가능등의 옵션이 포함됨
rows: 데이터 배열
header: 데이터테이블 상단에 표시되는 제목
cellStyleOption: 셀에 적용되는 스타일관련 옵션들
emptyRender: 조회 전이거나, rows가 빈 값일 때 표시되는 내용 (React Component 타입)
paginationOption: 페이지네이션 관련 옵션들

만약 이 컴포넌트를 호출한다면 아마 이런 모양일 것이다.

너무 추잡하다.

기능이 늘어날수록 외부에서 넣어줘야하는 값들이 늘어날 것이다.
기본값을 활용하면 줄일 수는 있겠지만,
그것만으로 다양한 바리에이션의 요구사항을 만족하기는 역부족이다.

---

개선 방법 1: 바리에이션 명시하기

아예 명시적으로 다양한 바리에이션에 대한 옵션을 지정하는 방법이 있다.
(나중에 나오지만 추천하지 않는다)

장점
전달해야하는 여러가지 prop을 생략할 수 있다.
종류가 몇가지 안된다면 편할 수 있다.

단점
종류가 많아지면 복잡해진다.
커버 가능한 경우의 수에 한계가 있다.

예를 들어 propA, propB, propC에 각각 5가지 입력의 경우의 수가 있다면,
총 5 x 5 x 5 = 125의 경우의 수가 나오지만,
개발자가 타입을 명시하게 되면 특정 경우만 지정이 가능하고,
새로운 요구조건이 들어올 때마다 컴포넌트에 지정해줘야한다.

눈앞의 요구사항을 쳐내는데에 급급해서 하게되면
나중에 피눈물을 흘리는 케이스다.

왜 피눈물을 흘리는지는 나도 알고 싶지 않았다 ㅠㅠ

---

개선 방법2: 자주 사용하는 옵션을 상수로 빼기

코드의 직관성과 옵션의 재활용을 고려하기 시작하면,
자주 사용하는 옵션들을 상수로 관리할 수 있다.

장점
특정한 옵션을 재활용할 수 있다.
옵션과 컴포넌트를 파일을 분리하여 관리할 수 있다.

단점
일괄적인 변경요청에 취약할 수 있다.
묶여서 사용하는 옵션들이 있을 때, 변경에 대한 관리가 어렵다.

---

일괄적인 변경요청의 예시를 들어보자.
A, B, C 페이지 모두 paginationA 옵션을 사용한다.

그런데 A, B는 같은 구성의 페이지이고,
C는 전혀 다른 페이지의 구성이지만 옵션은 paginationA를 쓰고 있다.
(겹칠수는 있으니까)

그런데 A, B와 같은 레이아웃에 일괄적으로 다른 페이지네이션을 적용하게 되었다.
그렇다면 개발자 입장에서의 해결방법은
paginationA를 전체검색을 해서 변경된 페이지만 paginationB로 변경하거나,
각 페이지 코드에 찾아 들어가서 수정을 해줘야 한다.

예시라서 2개만 바꾸면 되지만,
프로젝트의 규모가 있다면 수십개 변경을 각오해야 한다.

---

묶여서 사용하는 옵션의 예시를 들어보자.

예를 들어 위의 경우와 같이 A, B, C가 있다고 생각해보자.
A와 B는 페이지 맥락상 비슷한 구성이다.
예를 들면 메일함의 받은 메일함과 즐겨찾기같이.

그런데 이 둘이 같은 구성이라는 것을 코드만 보고서는 파악이 어렵다.
또한 같은 구성의 일괄 변경이 있을 때, 
특정 구성만 검색하기가 어렵다. 
단순히 paginationA로만 검색하면 C도 검색이 될 테니까.

---

개선 방안 3: 옵션 그룹의 관리

이게 생각한 방식이다.
기존에 이미 있는 방식인지는 모르겠다. 있다면 댓글로 용어를 알려주셨으면.

옵션을 그룹으로 묶어서 관리하는 방식이다.
백문이 불여일견. 코드로 보자.

주요한 값들 (rows, columns, header)을 제외하고는 
대부분을 세트로 묶어서 관리했다.

일괄적인 변경 요청에도 세트를 수정하면 된다.

---

한계

자 일단 생각은 해봤는데...
한계가 일단 여럿있다.

1. 일을 위한 일이 생긴다.
(호출부는 가벼워지지만, constants가 verbose해진다)

2. 일괄적인 변경을 예측하기 어렵다.
예를들어 A, B, C 페이지 모두에 변경이 있다고 한다면...
또는 C와 같은 구성의 D도 DATA_TABLE_TYPE_B를 공유하고 있었는데,
C만 바뀌고 D는 그대로라면...

---

마무리

오 나 개천재인데 생각해보고 써보니
역시 안 쓰는데에는 이유가 있다.

한층 겸손해진 하루였다.

그래도 딱 맞는 상황에 쓰면 괜찮을듯?