#5 프로덕트 상세보기 페이지 구현

Link

 

Issue: https://github.com/spring-bud/mate-fe/issues/12

PullReq : https://github.com/spring-bud/mate-fe/pull/13

 

기술적 구현

2025.01.18 - [React/React-query] - 서버컴포넌트에서 리엑트쿼리(prefetch)

 

 

1. 리엑트쿼리 prefetch로 서버컴포넌트에서 데이터 페칭 후 캐싱

2. customImage로 user이미지 렌더링과정에서 오류생길시, 대안이미지 렌더링

3. SEO를 고려한 시멘틱태그 

 

고민&의사결정 과정

프로젝트를 설계하면서 가장 중점을 둔 것은 컴포넌트의 관심사 분리와 폴더 구조의 체계화였다. 

폴더구조를 서버컴포넌트와 클라이언트 컴포넌트로 나누고, 데이터 페칭 및 관련 API호출은 Smart한 컴포넌트에서 다루고 하위 컴포넌트들은 오직 UI만을 담당하여, 관심사를 완벽하게 분리하려고 했다.

 

다시 정리하자면,

app/product/[id]/page.tsx 에 서만 Smart를 다루고 

 

 

app/Product/[id]/ui/ui.tsx 

app/Product/[id]/section/(프로덕트페이지에서만 사용하는 컴포넌트)

 

두 곳에선, 오직 Ui만 담당하려했다. 

 

그러나, 리엑트쿼리를 통해 서버데이터를 클라이언트측에서 관리하기 위해선, 필수적으로 조정이 필요했다.

 

따라 다음과 같이 분류했다.

 

app/products/[id]/
├── page.tsx           # 서버 컴포넌트 (데이터 페칭, prefetch, 메타데이터)
├── ui/
│   └── Ui.tsx        # 클라이언트 컴포넌트 (React Query, 클라이언트 상태 관리)
└── sections/         # 순수 UI 컴포넌트
    ├── MainContent.tsx
    ├── Profile.tsx
    └── Reviews.tsx

 

이러한 구조의 주요 설계 원칙은 다음과 같다

 

1. 관심사의 명확한 분리

• page.tsx: 서버 사이드 로직과 데이터 페칭그리고 SEO를 위한 메타데이터 전담
• ui/Ui.tsx: 클라이언트 상태 관리와 데이터 캐싱을 담당(prefetch로 캐싱된 데이터)
• sections/: 순수하게 UI 렌더링만을 담당하는 프레젠테이셔널 컴포넌트

2. 책임의 계층화

• Smart 컴포넌트(page.tsx, Ui.tsx)와 Dumb 컴포넌트(sections/)를 명확히 구분
• 데이터 흐름의 단방향성 유지
• UI 로직과 비즈니스 로직의 분리

특히 React Query의 도입으로 인해, 클라이언트 상태 관리가 필요한 부분을 Ui.tsx에 집중시켰다. 이는 서버 컴포넌트의 순수성을 해치지 않으면서도, 클라이언트 측의 데이터 관리를 효율적으로 수행을 노릴 수 있을 것 같았기 때문.

 

앞으로의 확장성을 고려하여, Ui.tsx에서는 클라이언트 측 상태 관리와 데이터 조작을 담당하되, 여전히 비즈니스 로직과 UI를 분리하는 원칙을 유지할 계획이다. 

 

개선되야 할 사항

• 디자인 관련하여 프로젝트의 전반적인 width 조정 필요
• 서버컴포넌트에서 Prefetching시, Ui관련 스켈레톤 디자인
• 리엑트쿼리와 Suspense 조합

학습사항

리엑트쿼리 Prefetch

에러슈팅

...

참고자료