오늘 약 1시간 동안 컴포넌트 분리에 대해서 같은 아티클을 읽어보는 시간을 가졌다.
프론트엔드 아키텍처: 컴포넌트를 분리하는 기준과 방법
분리 기준
저자는 컴포넌트를 웹 앱을 구성하는 데 있어 가장 작은 단위로 규정하고 그 컴포넌트를 어떻게 나눌 것인가에 대한 기준을 재사용성과 복잡성에 의거해 제시했다.
- 재사용한 가능한 컴포넌트
- 복잡한 컴포넌트
- 렌더링 퍼포먼스
재사용 가능한 컴포넌트
저자는 해당 부분에서 재사용 가능한 컴포넌트들을 만들 때 주의점을 설명하고 있는데
"중복 제거와 관련된 DRY원칙은 중복을 겉모습으로 판단하지 않습니다. 만약 모습이 같은 코드가 같은 이유로 수정된다면 그 코드는 중복입니다. 하지만 같은 모습의 코드라도 수정의 이유가 다르다면 두 코드는 중복이 아닙니다"
겉모습 뿐만 아닌 수정의 이유도 같아야지만 중복이라고 설명하고 있다. 이 말이 솔직히 잘 이해가 되질 않는다 수정의 이유...
재사용 컴포넌트를 만들때 조건문이 추가된다라는 것은 재사용 컴포넌트를 사용하는 컴포넌트들이 서로 다른 수정의 이유를 갖는다는 것을 의미하고 그렇기 때문에 해당 컴포넌트는 중복이 아니기 때문에 해당 컴포넌트는 재사용 컴포넌트로 만든 것이 아니게 된다고 설명한다...
다음으로 언급한 것은 의존성인데 상위 컴포넌트가 재사용을 위한 하위 컴포넌트에 의존적이라는 것이데 이러한 의존성은 수정이나 변경 요구가 있을 때 더 많은 수정과 변경을 해야 한다는 문제점이 생긴다.
이 문제들을 해결하는 방법 중 하나는 정말 공통적인 부분만 남겨두고 사용하는 컴포넌트의 고유한 것은 속성으로 전달하는 것이다.
위 말은 리액트 공식문서에서도 제공하는 방식으로 children 속성을 이용하여 의존성 문제와 중복의 문제를 해결한다.
function Card({children}) {
return (<section>
<h3>...</h3>
<p>가격...</p>
{children}
</section>)
}
function ParentCard1() {
return <Card />
}
function ParentCard2() {
return (<Card>
<p>요약...</p>
</Card>)
}이러한 방식으로 의존성문제 해결하는 것을 의존성 주입이라고 표현한다고 한다.
복잡한 컴포넌트
컴포넌트가 복잡해지는 이유는 여러가지가 있는데 저자는 그 중에서 2가지에 대해서 설명한다.
- 컴포넌트에 비지니스 로직이 있는 경우
- 컴포넌트가 여러 책임을 갖는 경우
비즈니스 로직
비즈니스 로직은 변경의 빈도가 UI의 변경의 빈도보다 더 느리다.
이러한 비즈니스 로직이 컴포넌트에 포함되어 있다면 빈번한 UI 변경에 따라 자주 영향을 받을 수 있는데 사실 다른 아티클을 더 읽어봐야하는 부분들이 있어서 중요한 것은 이러한 비즈니스 로직은 분리를 해야 한다라는 정도로만 이해했다.
컴포넌트의 여러 책임
이 "책임"이라는 단어는 굉장히 많이 들어본 단어이다. 단일 책임, 단일 기능, 하나의 책임, 하나의 기능이라는 것은 무엇을 뜻하는 것일까? 굉장히 추상적이고 주관적인 개념이다.
리액트 공식문서의 Thinking in React에서는 컴포넌트는 이상적으로 한 번에 한 가지 일만 해야 한다고 설명한다.
얘기를 나누면서 이 한가지 일에 대해서 굉장히 많은 얘기가 오갔고, 결론은 만든 사람 마음이라는 것이다. 내가 생각한 내용이 충분히 논리적이고 합리적인 근거가 있다면 그 생각은 다른 생각일 뿐 결코 틀린 생각이 아니라는 것이다.
렌더링 퍼포먼스
마지막은 살짝 빠르게 끝난 감이 있다. 서로 영향을 주지 않는 컴포넌트들은 하나의 상위 컴포넌트에서 상태를 관리하는 것이 아닌 하위 컴포넌트 자체에서 상태를 관리하여 렌더링 퍼포먼스를 기준으로 나누는 방법을 제시하고 있다.
결론
여러 방법과 기준들이 제시되고 있지만 결국 정답은 없고 내가 어떤 기준과 생각을 가지고 컴포넌트를 분리했는지에 대해서 남에게 설명할 수 있는 힘을 길러야겠다라는 생각을 가졌다.
