optrader dac4e8f81c [251104] fix: UserReviewPanel 필터 캐싱 버그 해결
필터링된 리뷰 데이터가 상품 변경 후에도 유지되는 문제를 해결했습니다.

**문제:**
1. 상품 A에서 필터(5 star) 적용 후 Back
2. 상품 B로 이동 시 상품 A의 필터링된 리뷰 데이터가 계속 표시됨
3. 리뷰가 없는 상품은 [Show User Reviews] 버튼이 안 보임
4. 리뷰가 있는 상품도 필터 미적용 전까지 이전 리뷰가 노출됨

**근본 원인:**
- Redux의 filteredReviewListData와 currentReviewFilter가 상품 변경 후에도 유지됨
- useReviews 훅이 새로운 상품 로드는 하지만 필터는 초기화하지 않음

**해결책:**
1. useReviews 훅: prdtId 변경 시 자동으로 clearReviewFilter() dispatch
2. ProductAllSection: productData.prdtId 변경 시 필터 초기화
3. UserReviewPanel: Back 버튼 클릭 시 Redux 필터 명시적 초기화

**수정 파일:**
- src/hooks/useReviews/useReviews.js (필터 초기화 로직 추가)
- src/views/DetailPanel/ProductAllSection/ProductAllSection.jsx (상품 변경 감지)
- src/views/UserReview/UserReviewPanel.jsx (Back 버튼에서 필터 초기화)

🤖 Generated with Claude Code

Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-04 16:04:21 +09:00
2025-09-12 14:10:43 +09:00
2024-10-14 17:31:11 +09:00
2025-06-30 00:51:34 +00:00
2025-06-30 00:51:34 +00:00

ShopTime

LG ShopTime Project

브랜치 관리 전략

프로젝트는 다음과 같은 브랜치 구조로 관리됩니다:

주요 브랜치

  • main

    • 최종 릴리즈 및 검증이 완료된 소스 코드 보관
    • 매주 목요일: QA 브랜치에서 검증 완료된 코드를 main으로 병합
  • qa

    • 2차 테스트 및 최종 릴리즈 검증용 브랜치
    • 매주 화요일: 배포 진행
    • 매주 수요일: 검증 진행
  • qa2

    • 1차 테스트용(qa2 배포) 소스 코드 보관
    • LG 깃 레포지토리의 QA2 브랜치와 동기화 필수
  • develop

    • 고도화 작업 및 유지보수팀 코드 통합 브랜치
    • 기능 개발 완료 후 코드 리뷰를 거쳐 해당 브랜치로 병합

작업용 브랜치

  • hotfix

    • 유지보수팀 전용 브랜치
    • 수정 완료 후 develop 브랜치로 병합
  • feat/name_v2

    • 고도화 작업팀 전용 브랜치
    • 기능별로 별도 브랜치 생성 필요
    • 예: feat/home_v2, feat/search_v2
    • 작업 완료 후 develop 브랜치로 병합

배포 프로세스

  1. 화요일

    • QA 브랜치 배포
    • QA2 → QA 브랜치 병합
  2. 수요일

    • QA 브랜치 검증 진행
  3. 목요일

    • QA → Main 브랜치 병합
    • Main 브랜치 릴리즈

커밋 메시지 컨벤션

고도화 작업

  • [branch name]Type : 작업내용
  • git commit -m "[home]feat : 선택약관 동의시 배너 나타남"

유지보수 작업

  • [jira task Number]Type : 작업내용
  • git commit -m "[SHOPTIME-4020]fix : pdf open test"

Type

  • feat: 새로운 기능 추가
  • fix: 버그 수정
  • docs: 문서 수정
  • style: 코드 포맷팅
  • refactor: 코드 리팩토링
  • test: 테스트 코드
  • chore: 빌드 업무 수정

긴급 배포 프로세스

  1. 긴급 수정 사항 발생 시

    • hotfix 브랜치에서 작업
    • 담당 PM 및 리드 개발자 승인 필수
  2. 긴급 배포 승인 시

    • hotfixqa2 병합
    • QA2 검증 진행
    • 검증 완료 후 qamain 순차적 배포
  3. 배포 후 조치

    • 긴급 배포 내역 문서화
    • 재발 방지 대책 수립
    • develop 브랜치에도 수정사항 반영
Description
No description provided
Readme 177 MiB
Languages
JavaScript 83.3%
Less 16.7%