뷰를 추상화하는 것
잘 설계한 컴포넌트 = 뷰를 적절한 단위로 잘 추상화한 것
쇼핑 웹 사이트를 예로 들어보자. 전체적인 리스트를 담당하는 productList
컴포넌트와 하나의 아이템을 담당하는 productItem
컴포넌트가 있다.
요구사항
각 아이템의 개수를 사진 안으로 옮기고 가격을 가운데 정렬 해주세요
해결
우리는 추상화해놓은 productItem
의 css를 조금만 건들면 된다.
이렇게 추상화하기 쉬운 경우도 있지만 애매한 경우도 있다.
다른 곳에서 같은 기능을 하는 하나의 컴포넌트
장바구니 -> 결제예상금액
주문 목록 상세 -> 결제금액
위를 보면 두 컴포넌트는 하나의 컴포넌트로 추상화할 수 있을 것 같다. 대신 장바구니에는 주문하기
기능이 있고 주문 목록에는 없다.
요구사항1
장바구니
'결제예상금액'에서 쿠폰을 적용하게 해주세요
문제점1
추상화한 컴포넌트를 다시 변경해야 되는데 여기서 사이트 이펙트가 생긴다. 장바구니에서만 컴포넌트가 바뀌어야 하지만 주문 목록에서도 바뀌는 것이다. 결국 큰 단위에서 분기를 처리해야 한다.
요구사항2
장바구니
'결제예상금액'에 마일리지도 적용해주세요.
주문상세
'결제금액'에 결제 날짜도 추가해주세요.
문제점2
가벼운 컴포넌트로 추상화해서 쉽게 대응하려고 했지만 공통점보다 차이점이 많아지는 문제가 발생한다. 다른 사람이 코드를 봤을 때 어떤 기능을 하는지 이해가 잘 안되고 추가 요구사항이 들어올 때마다 어떻게 추상화해야 할지 난처해진다.
UI가 아니라 모델 기준으로 컴포넌트를 분리한다
도메인이 다르다 -> 모델이 달라질 확률이 높다!
방법
공통된 요소의 중복이 있다 해도 다른 컴포넌트로 분리한다.
장점
다른 요구사항이 들어와도 쉽게 변경 가능하다.
예외
모델/도메인이 다르지만 동일한 UI가 보인다면..
- 범용 컴포넌트 또는 디자인 시스템으로 추출한다.
- 중복 구현하고 지켜본다.
2번에 대한 설명
추상화가 복잡해진다? 중복코드를 인라인(복붙)한다. 도메인이 다르면 중복 코드도 각각 달라지게 되는데 더 유의미한 추상화가 나올 수 있다.