✍️ 시작하며
A : "이런 케이스가 이 프로젝트에 있을까요?"
B : "당장엔 없을 수도 있지만, 나중에 생기지 않을까요?"
A : "리소스 낭비이지 않을까 싶은데..."
B : "그래도 하나의 함수에서 여러 로직을 처리하기 보단 기능들을 조합해서 쓰는게 적합하다 생각하는데요.."
작은 컴포넌트를 설계하다 보면 이런 고민에 부딪히게 된다.
어떤 기능을 처리할 때, 컴포넌트 API를 활용해서 개발해야 하는데,
그 API를 만들 때 프로젝트에서 요구하는 기능을 직접적으로 구현할 것인가,
아니면 기본적으로 필요한 API들을 구현해두고, 사용하는 쪽에서 조합해서 쓸 것인가.
어찌 보면 컴포넌트를 해당 프로젝트에 딱 맞춰 쉽게 쓰려면 직접적인 기능을 구현하는 게 맞다.
하지만 폭넓게 재사용하고자 한다면, 기능을 분리해 조합할 수 있도록 만들어두는 게 낫지 않을까 하는 생각도 든다.
🤔 이번에 부딪힌 고민
Wijmo FlexGrid 데이터 테이블을 커스텀한 컴포넌트가 있다.
그리고 페이지 개발자에게 추가 기능 요청이 들어왔다.
"특정 row를 select 시켜주는 기능이 필요합니다."
특정 row를 선택하는 기능을 만들어야 했다.
그런데 고민이 생겼다.
데이터 테이블은 단일 선택과 다중 선택 옵션이 있다.
- 단일 선택이라면 기존 선택을 해제하고, 새로운 row 하나만 선택되면 된다.
- 다중 선택이라면,
- 기존 선택을 유지하면서 새로운 row를 추가할 것인가?
- 아니면 기존 선택을 모두 해제하고, 새로 추가할 것인가?
개발자들과 이야기하던 중 나온 이야기다.
"이 프로젝트엔 저런 케이스가 없을 것 같긴 한데..."
물론 교체 방식(기존 해제 후 새로 선택) 으로 구현하면 더 간단하다.
하지만 이 프로젝트는 프레임워크처럼 배포되어 다양한 커스터마이징이 들어갈 예정이다.
그때마다 해당 케이스가 "없다"고 단언할 수 있을까?
이게 계속 마음에 걸렸다.
📚 어떻게 하기로 되었나.
여러 방안을 생각해봤다.
- 선택할 row들의 유니크값 배열을 매개변수로 넘기고,
- 거기에 "덮어쓸지, 추가할지"를 구분하는 옵션을 추가하는 방법.
하지만 이렇게 하면:
-
제거만 필요한 상황이 복잡해진다.
-
하나의 함수가 추가/제거를 모두 담당하면서 책임이 불분명해진다.
그래서 결국 "추가하는 함수", "제거하는 함수" 두 가지를 나누기로 했다.
그렇게 하면:
-
"반전"이 필요한 경우 → 제거 함수 호출 후 추가 함수 호출
-
"추가만" 필요한 경우 → 추가 함수 호출
-
"제거만" 필요한 경우 → 제거 함수 호출
로 명확히 사용할 수 있다.
💬 정리하며
프로젝트 특성에 "딱 맞춰서" 기능을 만드는 게 가장 쉽고 빠른 길이다.
하지만 장기적으로 보면,
컴포넌트는 항상 "작고, 범용적"이어야 한다.
내부는 최대한 단순하게.
복잡한 요구사항은 밖에서 조립해서 해결할 수 있어야 한다.
이게 지금 내가 컴포넌트를 만들 때 가장 중요하게 생각하는 점이다.
