🔮[좋.코.무] Reusable Component🔮

아마 프론트엔드 개발자라면 "Reusable Component"이란 말을 들어봤을꺼라 생각되는데. (왜냐하면 나도 들어봤으니까)
그래서 Reusable Component를 만드려면 어떻게 해야할까 고민을 많이 했어.

💎Reusable Component

Reusable이란 재사용성을 뜻하는데, 다시말해 내가 만든 컴포넌트를 여기서도 쓰고 저기서도 쓰고 여러군데에서 쓸수 있어야한다는 거야.

💎딜레마

한동안 재사용성이 높은 컴포넌트를 만드는데에 감이 안왔었다. 처음에 컴포넌트를 만든다는 것은 중복되는 html, css 코드들을 컴포넌트로 만들어서 재사용하려고 했지. 그런데 재사용성을 어디까지 높여야하는지 몰랐던거야. 재사용성이 높으려면 사실 그냥 library의 컴포넌트처럼 만드는게 맞지. 스타일을 모두 정해주고 안에 들어가는 컴포넌트도 정해주는 거지. 근데 재사용성이 너무 높아버리면 굳이 컴포넌트를 만드는게 의미가 있을까 싶었어. 결국 반복되는 여러줄의 코드가 많아졌거든.

💎컴포넌트 안좋은 예 (Feat. 과거의 나)

그래서 내가 처음 만든 컴포넌트들은 정말 내가 한 첫 기획(UI/UX 기획 및 디자인도 내가 했다ㅜ)에 맞춤으로 만들었어. 그러다보니 컴포넌트들이 state를 가지고있었고 아예 비즈니스 로직이 담긴 컴포넌트를 만들기도 했지. (와우, 최악이었네)
예를 들어서 모든 아파트 정보를 가져와서 리스트로 보여주는 컴포넌트를 만든거지. 그럼 아파트 리스트 컴포넌트가 데이터 콜도 하고 콜하는동안 로딩중이면 스켈레톤 ui도 보여주고 그러다 로딩이 끝나면 데이터를 보여주는 식이었던 거야.
이렇게 만들다보니 비슷한 UI를 가지고 있지만 하는 일이 달라서 새로 컴포넌트를 만들어야 할 경우도 있었고 기존 컴포넌트에 코드에 코드를 더해야 할때도 있었어. 로직과 UI가 나눠지지 않아서 내 코드밭을 뒤져가며 찾아야할 때도 있었어.
내가 100퍼센트 짠 코드인데 "이 컴포넌트는 뭐하는 애였지?", "이건 무슨 데이터지?" 등 꼭 남의 코드 보듯이 개발을 진행해 나갔지.

💎컴포넌트 개선

이렇게 개발을 한지 어언 4개월. 어느정도 UI가 완성되고 내가 생각한 좋은 코드의 기준이 잡혀간 시점에 난 느껴버렸어. 지금이 아니면 이 혼돈의 카오스인 내 코드들을 정리할 기회가 없겠다 싶었지. 그래서 코드를 다 뜯어고치기로 마음먹었다. 사실 컴포넌트 말고도 전부 다 정리해야 했거든. interface도 여기저기 흩어져있고 데이터 fetching하는 것도 여기저기 흩어져있었거든. 거의 사혼의 구슬 조각 모으는 느낌.

코드들을 뜯어고치기 전, 일단 컴포넌트의 기준을 세웠어.

• 컴포넌트는 UI만 담당하는 코드이다. 컴포넌트가 state나 데이터 자체를 가지고 있지 않도록 하자.
• 가능한한, 모든것을 컴포넌트로 만들 되, 중복되지 않도록 한다.

첫번째 기준은 컴포넌트의 정의와 마찬가지지.
두번째는 Layout까지도 컴포넌트를 만들려는 의도야. 내가 하고싶었던거는 (컨테이너컴포넌트)X(레이아웃컴포넌트)X(기본컴포넌트)였거든. 예를 들어

위의 그림을 예를 들면 카드외형을 맡고 있는 흰색 둥근 부분이 컨테이너컴포넌트이고 1, 2, 3, 4가 세로 한줄로 들어가 있는 레이아웃이 레이아웃 컴포넌트인거고 1,2,3,4가 기본컴포넌트인거지.
이렇게 기준을 세우고 나니 Reusable Component가 무엇인지 감이 오더라고.
공통되어야 할 스타일은 컴포넌트가 가지고 있고 변화할 스타일은 인자로 받는거지.

그리고 Next.js나 React에서 컴포넌트는 상위 컴포넌트에게 값을 받아야 하거든. 근데 만약 컴포넌트가 컴포넌트를 가지고 그 컴포넌트가 컴포넌트를 가지고 이렇게 뎁스가 많아질때는 데이터를 내리고 내리고 내리는게 너무 비효율적이잖아.

그래서 나는 이것을 해결하기 위해서 컴포넌트를 컨테이너 컴포넌트와 기본 컴포넌트로 나눴어.
컨테이너 컴포넌트는 기본 컴포넌트를 children을 prop으로 받는거지. 그렇게 되면 내가 컨테이너 컴포넌트에 데이터를 넣어 그 안에 있는 컴포넌트로 전달하는게 아니라 pages 단에서 바로 데이터를 넣어서 줄 수 있지.

💎한번 더!! 개선

🎯전역 변수 및 Function 사용

예를 들어 내가 정한 메인 color가 "indigo-500"이라고 가정했을때, 모든 theme이라는 색을 쓰는 컴포넌트에 indigo-500을 적는것보다는 const themeColor = "indigo-500"이라고 쓰고 themeColor를 가져와서 쓰는게 고민 안해도되고 편리하고 좋잖아? 색을 바꿀때에도 themeColor의 값만 바꿔주면 한번에 바뀌니까 유지보수에도 좋을꺼고. function도 마찬가지일꺼지.
그래서 나는 Recoil을 쓰기로 결정했어. 일단 가장 큰 이유는 배우기 쉽기때문이야. 더 자세한 내용은 추후에 내가 직접 사용해보면서 다시 업로드할께.

🎯컴포넌트의 컴포넌트

이 개념은 아직 완성된 개념은 아니고 조금 더 공부도 필요한 개념인데, 내가 이 개념을 고민한 이유는 다음과 같아.

• 특정 컴포넌트 안에 특정 컴포넌트가 특정한 일정한 스타일을 가지고 들어가는 경우

예를 들어서 버튼이라는 컴포넌트가 있는데 이 버튼은 작은사이즈, 중간 사이즈, 큰 사이즈 세가지를 prop으로 받아. 근데 리스트 카드라는 컨테이너 카드 안에 들어가는 컴포넌트 카드는 항상 작은 사이즈의 버튼이 들어가. 버튼이 안들어갈 때도 있고. 그럴경우 class처럼 다음 방식처럼 쓰고 싶은거지.

<Card>
  <Card.Layout type="세로">
	<Card.Button onClick={doSomething}>
  		클릭해주세용
	</Card.Button>
  </Card.Layout>
</Card>

당연히 Card 안에는 그냥 일반 Layout이나 Button컴포넌트도 들어갈 수 있지. 하지만 그때마다 모든 컴포넌트를 만들어서 쓰다보면 디자인 통일성도 적어질 거잖아?
어떻게 보면 default 컴포넌트를 만들고 싶은거지.
(+Headless UI라는 라이브러리는 이런식으로 쓰는 것 같더라구. 그래서 라이브러리를 열어보는 중이야.)
이 개념도 완성되면 추후 업데이트 할께. 업데이트 했뜨아!!
+내용추가
생각보다 쉽더라고!
위의 코드처럼 Card 전용 Button이 필요할 때는 Card 컴포넌트가 있는 파일로 가서 일반 컴포넌트를 작성해주듯이 만들어주면 되더라고. 그리고 마지막에 Card.Button 한줄을 추가해주면 위의 예처럼 Card.Button으로 사용이 가능한거지.

//Card.tsx
interface CardProps {
	children: React.ReactNode;
}
export default Card({
  children,
}: CardProps) {
  return (
    	<div>
    		{children}
    	</div>
    )
}

interface ButtonForCardProps {
    clickEvent?: () => void;
    children: React.ReactNode;
}
function ButtonForCard({
    clickEvent,
    children
}: ButtonProps) {
    return (
        <button onClick={clickEvent}>
            {children}
        </button>
    )
}

Card.Button = ButtonForCard;

여기에서 중요한 점은 다음과 같아.

• export를 사용하지 않아도 상위 컴포넌트(Card)만 import해서 사용하면 그 아래의 모든 Component는 자동으로 사용할 수 있어.
• 대신 Card 안에서만 사용할 수 있어. Card 밖에 사용할 수 없는거지

위에서 export를 따로 해주지 않아도 상위 컴포넌트만 import해도 그 아래의 모든 component를 사용할 수 있지.
하지만 하위 컴포넌트가 불필요하게 많아지면 당연히 불필요한 코드들도 같이 import 해오기 때문에 주의해야할 것 같아.

💡결론

• 프론트엔드에서 컴포넌트는 UI에만 초점을 맞추도록 한다.
• 재상용성이 높은 컴포넌트를 만들어야한다.
• 재사용성이 높을수록 자유도가 높아져 브랜드 통일성이 낮아지기 때문에, 이를 보안해주는 기능이 필요하다.