이채민

카드 컴포넌트 스타일링 재사용 방식 비교

tailwindcss @components vs 스타일링된 컴포넌트 별도 정의 방식 <Card></Card>

1. @components 는 가독성은 후자에 비해 떨어지지만 태그, 스타일링 등을 확장하기 수월

// global.css
@layer components {
  .card { ... }
}

// 활용
<div className="card 덮어쓸_스타일">...</div>
<section className="card">...</section>

1. 컴포넌트 정의시 가독성은 높지만 커스텀을 위해서는 props로 넘겨야한다는 불편함과 다른 태그 사용 안됨.

function Card({className, children}){
	// className을 상속받아 추가
	return <div className={`스타일 ${className}`}>{children}</div>
}

// 활용
<Card></Card>

→ 단순 배경색 뿐 아니라 커스텀되어야하는 스타일링이 많아 tailwindcss @components 채택

필터링을 가지는 리스트 모두 클라이언트 컴포넌트로 구현해야하는가?

1. CSR을 최소화하자 - 서버 컴포넌트만을 활용 할 순 없을까?

   → path variable을 활용하여 서버 컴포넌트로 일괄 변경 /funding/{category}

2. 카테고리와 정렬을 모두 가지는 리스트의 경우는 어떻게 처리할 것인가?

   모두 path variable로 나타내기에는 URL 설계 방식에 어울리지 않아보임

   e.g. payments/{category}/{filter}

   → searchParams를 함께 활용하자 /all?sort=latest

3. 잘못된 params와 searchParams를 판별하는 validation 로직 필요

   Layout에서 해당 로직 추가 시도

   but, layout.tsx 같은 경우에는 하위 페이지간 navigation 동안에는 re-rendering 되지 않음!

   → layout.tsx 에서는 params만, page.tsx에서는 searchParams를 validate하기로 함

4. 뒤로가기 클릭시 홈으로 이전 페이지로 이동하길 바라는 사용자의 기대와는 달리 이전에 선택한 카테고리 탭으로 이동하는 문제 발생

   • 영상자료

   라우팅 히스토리를 관리하기 위해서는 클라이언트 컴포넌트여야함.

   → 모든 필터가 삽입된 리스트페이지를 클라이언트 컴포넌트로 변경

<aside> 💡

use client 를 사용하는 것에 죄책감을 갖지 말자!

클라이언트/서버 컴포넌트는 각각의 장점이 존재하며,

이를 적절히 섞어 사용할 수 있는 것이 Next.js의 특징. 잘 활용하도록 하자

</aside>