Hotfix/95/fix type #102

HaeJungg · 2024-11-11T04:57:09Z

🔖 Issue Ticket

#95

✍️ Description

백앤드 타입에 따라서 데이터 관련 전체적인 타입을 수정했습니다.
dev로 실행시 목데이터는 타입이 달라 일부 undefined로 표시되는 내용이 있을 수 있습니다!

+훅 안의 파일들 컨벤션이 맞게 변경

✅ Checklist

PR

Branch Convention 확인

feat/ 피쳐, fix/ 버그 수정, refactor/ 개선
Base Branch 확인
적절한 Label 지정
Assignee 및 Reviewer 지정

Test

로컬 작동 확인

Summary by CodeRabbit

New Features
- 새로운 데이터 구조를 사용하여 크루 및 모임 관련 정보의 타입 정의를 개선했습니다.
- 모임 카드 및 크루 카드의 속성 이름을 변경하여 일관성을 높였습니다.
- 크루 목록 및 모임 목록의 데이터 처리 방식을 간소화했습니다.
Bug Fixes
- 데이터 구조 변경으로 인해 발생할 수 있는 오류를 수정했습니다.
Documentation
- 코드 내 주석을 업데이트하여 변경 사항을 반영했습니다.
Refactor
- 여러 컴포넌트에서 데이터 처리 방식을 간소화했습니다.
- 타입 정의를 중앙 집중화하여 가독성을 향상시켰습니다.

coderabbitai · 2024-11-11T04:57:17Z

Walkthrough

이 풀 리퀘스트는 여러 파일에서 데이터 구조와 타입 정의를 변경했습니다. .vscode/settings.json 파일에서는 TODO 주석에 대한 정규 표현식 하이라이트와 맞춤법 검사 사전이 수정되었습니다. next.config.mjs 파일에서는 CORS 헤더의 가독성을 높이기 위해 포맷이 조정되었습니다. 여러 API 파일에서는 데이터 타입이 변경되었고, 새로운 타입 정의가 추가되었으며, 기존의 타입이 제거되었습니다. 또한, 여러 컴포넌트에서 프로퍼티 이름이 변경되어 일관성을 높였습니다.

Changes

파일 경로	변경 요약
`.vscode/settings.json`	`cSpell.words` 배열에 "CODEIT"와 "pretendard" 추가
`next.config.mjs`	`Access-Control-Allow-Origin` 헤더 포맷 조정
`public/assets/images/crew-sample/index.tsx`	`ImgCrewSamples` 배열을 한 줄로 재포맷
`public/assets/images/gathering-sample/index.tsx`	`ImgGatheringSamples` 배열을 한 줄로 재포맷
`src/_apis/crew/get-crew-list.ts`	`getCrewList` 함수의 반환 타입을 `MainCrewListResponse`로 변경, 변수 이름 변경
`src/_apis/detail/get-crew-detail.ts`	`CrewDetail` 타입을 외부 모듈에서 가져오도록 변경
`src/_apis/detail/get-gathering-list.ts`	`GatheringList` 타입 제거, 반환 타입을 `GatheringType[]`로 변경
`src/_apis/getUser.ts`	`getUsers` 함수와 `User` 타입 제거
`src/_queries/crew-queries.tsx`	`mapCrewData` 함수 제거, 데이터 타입을 `MainCrewList[]`로 변경
`src/_queries/useGetUserQuery.ts`	사용자 데이터 쿼리 관련 함수 제거
`src/app/(crew)/api-test/page.tsx`	`TestPage` 컴포넌트 제거
`src/app/(crew)/crew/_components/gathering-detail-modal/gathering-detail-modal.stories.tsx`	`data` 객체의 프로퍼티 이름 변경
`src/app/(crew)/crew/_components/gathering-detail-modal/presenter.tsx`	`data` 객체의 프로퍼티 이름 변경
`src/app/(crew)/crew/detail/[id]/page.tsx`	`DetailCrewCard`에 `isConfirmed` prop 추가
`src/app/(crew)/my-crew/page.tsx`	`CrewCardInformResponse`를 `MyCrewListResponse`로 변경
`src/app/(crew)/my-gathering/creation/page.tsx`	`isLiked` 프로퍼티를 `liked`로 변경
`src/app/(crew)/my-gathering/participation/page.tsx`	`isLiked` 프로퍼티를 `liked`로 변경
`src/app/(crew)/page.tsx`	`useInfiniteScroll`의 타입을 `MainCrewListResponse`로 변경
`src/components/common/crew-list/crew-card-list.stories.tsx`	`CrewCardInformResponse`를 `MainCrewListResponse`로 변경
`src/components/common/crew-list/crew-card-list.tsx`	`CrewCardListProps` 인터페이스를 두 개의 인터페이스로 분리
`src/components/common/crew-list/crew-card.tsx`	`CrewCardProps` 인터페이스의 프로퍼티 변경
`src/components/common/crew-list/detail-crew-card.stories.tsx`	`CrewMembers` 프로퍼티를 `crewMembers`로 변경
`src/components/common/crew-list/detail-crew-card.tsx`	`CrewMembers` 프로퍼티를 `crewMembers`로 변경
`src/components/common/crew-list/profiles.tsx`	`ProfilesProps`의 `profiles` 타입을 변경
`src/components/common/gathering-card/container.tsx`	`GatheringCardContainerProps` 인터페이스에 `GatheringType` 추가
`src/components/common/gathering-card/gathering-card.stories.tsx`	`isLiked` 프로퍼티를 `liked`로 변경
`src/components/common/gathering-card/scheduled-gathering-card/container.tsx`	`isLiked`, `isGatherCaptain`, `isParticipant` 프로퍼티 이름 변경
`src/components/common/gathering-card/scheduled-gathering-card/presenter.tsx`	`isLiked` 프로퍼티를 `liked`로 변경
`src/components/common/gathering-card/scheduled-gathering-card/scheduled-gathering.stories.tsx`	`isLiked` 프로퍼티를 `liked`로 변경
`src/components/common/writable-gathering-card/writable-gathering-card.tsx`	`imageUrl` 프로퍼티를 `profileImageUrl`로 변경
`src/components/gathering-list/gathering-card-carousel.tsx`	`gatheringData` 타입을 `GatheringType[]`로 변경
`src/components/gathering-list/gathering-carousel.stories.tsx`	`isLiked` 프로퍼티를 `liked`로 변경
`src/mock/crew-data.ts`	`crewData` 구조 변경, 새로운 인터페이스 추가
`src/mock/gathering-data.ts`	`isLiked` 프로퍼티를 `liked`로 변경
`src/types/create-crew.d.ts`	`imageUrl` 프로퍼티 수정
`src/types/crew-card.d.ts`	여러 타입 정의 변경 및 추가
`src/types/gathering-data.d.ts`	여러 프로퍼티 이름 변경
`src/types/writable-gathering-card.d.ts`	`profileImageUrl` 프로퍼티를 선택적 필드로 변경

Possibly related PRs

🚑 Hotfix: 엔드포인트 변경 #86: HeaderPresenter 컴포넌트의 href 속성 업데이트와 관련된 변경 사항으로, .vscode/settings.json의 개발 환경이나 로컬 테스트 설정에 영향을 줄 수 있습니다.
Hofix/index page #91: CreateCrewForm 컴포넌트의 변경 사항은 사용자 입력 처리와 관련된 업데이트로, .vscode/settings.json의 맞춤법 검사 구성과 유사한 부분이 있습니다.

Suggested labels

fix

Suggested reviewers

User850413
minkyung5x5

🐰 변화의 바람이 불어와,
코드가 새롭게 태어나,
프로퍼티 이름이 바뀌고,
타입이 정리되어 가네.
모두 함께 웃으며,
더 나은 세상으로 나아가자! 🌟

Warning

There were issues while running the following tools:

🔧 eslint

src/app/(crew)/my-crew/page.tsx

Oops! Something went wrong! :(

ESLint: 8.57.1

ESLint couldn't determine the plugin "react-hooks" uniquely.

- /node_modules/eslint-plugin-react-hooks/index.js (loaded in ".eslintrc.js")
- /git/node_modules/eslint-config-next/node_modules/eslint-plugin-react-hooks/index.js (loaded in ".eslintrc.js » eslint-config-next/core-web-vitals » /home/jailuser/git/node_modules/eslint-config-next/index.js » plugin:react-hooks/recommended")

Please remove the "plugins" setting from either config or remove either plugin installation.

If you still can't figure out the problem, please stop by https://eslint.org/chat/help to chat with the team.

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

Review comments: Directly reply to a review comment made by CodeRabbit. Example:
- I pushed a fix in commit <commit_id>, please review it.
- Generate unit testing code for this file.
- Open a follow-up GitHub issue for this discussion.
Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
- @coderabbitai generate unit testing code for this file.
- @coderabbitai modularize this function.
PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
- @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
- @coderabbitai read src/utils.ts and generate unit testing code.
- @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
- @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

@coderabbitai pause to pause the reviews on a PR.
@coderabbitai resume to resume the paused reviews.
@coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
@coderabbitai full review to do a full review from scratch and review all the files again.
@coderabbitai summary to regenerate the summary of the PR.
@coderabbitai resolve resolve all the CodeRabbit review comments.
@coderabbitai configuration to show the current CodeRabbit configuration for the repository.
@coderabbitai help to get help.

Other keywords and placeholders

Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (`.coderabbit.yaml`)

You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
Please see the configuration documentation for more information.
If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

Visit our Documentation for detailed information on how to use CodeRabbit.
Join our Discord Community to get help, request features, and share feedback.
Follow us on X/Twitter for updates and announcements.

github-actions · 2024-11-11T05:00:03Z

🚀storybook: https://67206cc6ff9d7a05a3528ff8-clpzocofxp.chromatic.com/

coderabbitai

Actionable comments posted: 12

🧹 Outside diff range and nitpick comments (27)

src/_apis/detail/get-crew-detail.ts (1)
Line range hint 4-13: 빈 배열 처리에 대한 에러 핸들링이 필요합니다.

현재 구현은 응답 배열의 첫 번째 요소를 항상 사용할 수 있다고 가정하고 있습니다. 빈 배열이 반환되는 경우 response[0]은 undefined가 되어 런타임 오류가 발생할 수 있습니다.

다음과 같이 수정하는 것을 제안드립니다:
 export async function getCrewDetail(): Promise<{ data: CrewDetail }> {
   const response = await fetchApi<CrewDetail[]>('/crewDetail', {
     method: 'GET',
     headers: {
       'Content-Type': 'application/json',
     },
   });
 
+  if (!response.length) {
+    throw new Error('크루 상세 정보를 찾을 수 없습니다.');
+  }
+
   return { data: response[0] };
 }
src/_queries/crew-queries.tsx (1)
18-18: 데이터 변환 로직 단순화가 적절합니다.

데이터를 그대로 반환하도록 변경한 것이 코드를 더 단순하고 명확하게 만들었습니다. 다만, 주석을 좀 더 명확하게 작성하면 좋을 것 같습니다.

주석을 다음과 같이 수정하는 것을 제안합니다:
-    select: (data: MainCrewList[]) => data, // 그대로 반환
+    select: (data: MainCrewList[]) => data, // 백엔드 응답을 변환 없이 그대로 사용
src/_apis/crew/get-crew-list.ts (2)
Line range hint 6-15: API 응답 타입 처리가 개선되었습니다.

fetchApi의 제네릭 타입이 MainCrewListResponse로 올바르게 변경되었습니다. 하지만 응답 검증을 더욱 강화할 수 있습니다.

다음과 같은 타입 가드 함수 추가를 고려해보세요:
function isMainCrewListResponse(response: unknown): response is MainCrewList[] {
  return Array.isArray(response) && response.every(item => 
    'id' in item && 
    'title' in item
    // 필요한 다른 필드들도 검증
  );
}
22-24: 에러 메시지가 명확합니다.

에러 처리와 메시지가 적절히 구현되어 있습니다. 하지만 더 구체적인 에러 정보를 제공하면 좋을 것 같습니다.

다음과 같은 에러 처리 개선을 제안합니다:
- throw new Error('크루 리스트를 불러오는데 실패했습니다.');
+ throw new Error(`크루 리스트를 불러오는데 실패했습니다. 상세: ${error instanceof Error ? error.message : '알 수 없는 오류'}`);
src/components/common/crew-list/detail-crew-card.stories.tsx (1)
Line range hint 1-67: 스토리북 구성에 대한 제안

현재 스토리북 구성이 기본적인 사용 사례를 잘 보여주고 있지만, 다음과 같은 추가 스토리 구성을 고려해보시면 좋을 것 같습니다:

에러 상태 (예: 이미지 로드 실패)

로딩 상태

다양한 길이의 제목과 위치 텍스트

예시 구현:
export const Loading: Story = {
  args: {
    ...Default.args,
    isLoading: true,
  },
};

export const ErrorState: Story = {
  args: {
    ...Default.args,
    imageUrl: 'invalid-url',
  },
};

export const LongTitle: Story = {
  args: {
    ...Default.args,
    title: '매우 긴 제목의 모임입니다 이렇게 길게 작성되는 경우도 있습니다',
  },
};
src/app/(crew)/my-crew/page.tsx (1)

18-20: TODO 주석에 대한 구체적인 구현 계획 필요

TODO 주석이 있지만 구체적인 구현 방향이 명확하지 않습니다. 데이터 구조 변경에 따른 명확한 구현 계획이 필요합니다.

구현 방향에 대해 도움이 필요하시다면 GitHub 이슈를 생성해드릴 수 있습니다.

src/app/(crew)/crew/detail/[id]/page.tsx (1)

17-17: TODO 주석에 대한 추적이 필요합니다.

이 TODO 주석은 confirmed 부분이 향후 수정이 필요하다는 것을 나타냅니다. 이를 추적하고 관리하기 위해 GitHub 이슈를 생성하는 것이 좋겠습니다.

이 TODO 항목을 추적하기 위한 GitHub 이슈를 생성해드릴까요?
src/app/(crew)/my-gathering/participation/page.tsx (3)
Line range hint 11-11: 빈 useEffect 훅이 존재합니다

selectedDate 상태 변경에 대한 사이드 이펙트 처리가 비어있습니다. 불필요한 경우 제거하거나, 필요한 경우 적절한 로직을 구현해주세요.
-  useEffect(() => {}, [selectedDate]);
Line range hint 12-51: 반복되는 모크 데이터 구조 개선 필요

creationGatheringList의 각 객체가 동일한 구조로 반복되고 있습니다. 모크 데이터 생성을 위한 팩토리 함수나 유틸리티를 사용하여 코드를 더 간결하게 만들 수 있습니다.

다음과 같은 방식으로 리팩토링을 제안합니다:
const createMockGathering = (id: number, dateTime: string): GatheringCardProps => ({
  id,
  crewTitle: '풀 엔 그레이스 스튜디오',
  crewMainLocation: '서울시',
  crewSubLocation: '강남구 역삼동',
  title: '가나다라마가나다라마가나다라마가',
  dateTime,
  currentCount: 8,
  totalCount: 12,
  imageUrl: 'https://images.unsplash.com/photo-1601758260892-a62c486ace97?q=80&w=1470&auto=format&fit=crop&ixlib=rb-4.0.3&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D',
  liked: true,
});

const creationGatheringList: GatheringCardProps[] = [
  createMockGathering(1, '2024-10-30T00:30'),
  createMockGathering(2, '2024-10-30T00:30'),
  createMockGathering(3, '2024-10-31T00:30'),
];
Line range hint 61-63: 미사용 함수 제거 필요

파일 하단의 setState 함수가 사용되지 않고 있으며, 에러를 던지는 구현만 있습니다. 이 함수는 제거되어야 합니다.
-function setState(arg0: Date) {
-  throw new Error('Function not implemented.');
-}
src/components/common/gathering-card/container.tsx (2)
22-22: 상태 변수명의 일관성 개선이 필요합니다.

props에서는 liked를 사용하고 내부 상태에서는 isLiked를 사용하고 있어 일관성이 떨어집니다. 둘 중 하나로 통일하는 것이 좋겠습니다.

다음과 같이 수정하는 것을 제안드립니다:
- const [isLiked, setIsLiked] = useState(initialIsLiked);
+ const [liked, setLiked] = useState(initialIsLiked);

  const handleLikeToggle = () => {
-   setIsLiked((prev) => !prev);
+   setLiked((prev) => !prev);
  };
Also applies to: 41-44

에러 처리 및 UI 개선이 필요합니다

error 상태가 설정되어 있지만 사용자에게 표시되지 않고 있습니다:

GatheringDetailModalContainer가 열릴 때 에러 발생 시 사용자에게 알림이 없습니다.

에러 상태일 때는 모달을 열지 않거나 에러 메시지를 표시해야 합니다.

API 연동 관련 TODO 주석들이 여러 곳에 남아있습니다:

모임 상세보기 API 연동

모임 참여/탈퇴/삭제 API 연동

개선 제안:
useEffect(() => {
  const fetchGatheringDetail = async () => {
    setError(false);
    try {
      const data = await getGathering();
      setGatheringData(data);
    } catch (err) {
      setError(true);
      close(); // 에러 발생 시 모달 닫기
      // TODO: Toast 또는 에러 메시지 표시
    }
  };

  if (opened) {
    fetchGatheringDetail();
  }
}, [opened]);
🔗 Analysis chain

Line range hint 49-61: 에러 처리 개선이 필요합니다.

에러 상태(error)가 설정되어 있지만 UI에서 사용되지 않고 있습니다.

API 연동 TODO 주석이 남아있습니다.

에러 상태를 확인하기 위해 다음 스크립트를 실행해보겠습니다:

에러 처리 로직 구현이나 TODO 해결을 위한 코드를 제공해드릴까요?
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:
#!/bin/bash
# Description: 에러 처리 관련 컴포넌트 검색
rg "error.*message" --type tsx
Length of output: 60

Script:
#!/bin/bash
# Search for error handling patterns in TypeScript and React files
rg "setError|error\s*=" -A 5 -B 5 --type ts --type tsx src/

# Search for any error display components or UI elements
rg "Error|에러|실패" --type ts --type tsx src/

# Find the complete implementation of the gathering card container
fd "container.tsx" --exec cat {} \; src/
Length of output: 7848

Script:
#!/bin/bash
# Find the presenter component to check if error state is used in UI
cat src/components/common/gathering-card/presenter.tsx

# Search for any error message components or UI patterns
find src/ -type f -name "*.tsx" -o -name "*.ts" | xargs grep -l "Error\|실패\|오류"
Length of output: 5176
src/components/common/gathering-card/scheduled-gathering-card/container.tsx (1)

Line range hint 25-25: TODO 항목들의 추적이 필요합니다.

코드 내에 여러 TODO 주석이 있습니다:

modalData 연결

retry/refetch 구현

좋아요 토글 로직

이러한 미구현 기능들을 추적하고 관리하기 위해 GitHub 이슈로 등록하는 것이 좋겠습니다.

이러한 TODO 항목들을 GitHub 이슈로 생성해드릴까요?

Also applies to: 65-65, 71-71
src/app/(crew)/my-gathering/creation/page.tsx (3)
Line range hint 74-76: 사용되지 않는 함수를 제거해주세요.

setState 함수가 정의되어 있지만 사용되지 않고 있으며, 에러만 발생시키도록 구현되어 있습니다. 이 함수는 제거하는 것이 좋겠습니다.

다음과 같이 수정해주세요:
-function setState(arg0: Date) {
-  throw new Error('Function not implemented.');
-}
Line range hint 11-13: 빈 useEffect 처리가 필요합니다.

selectedDate를 의존성 배열에 포함하는 빈 useEffect가 있습니다. 이는 불필요한 렌더링을 유발할 수 있습니다.

다음 두 가지 방법 중 하나를 선택하여 수정해주세요:

useEffect가 필요한 경우:
-  useEffect(() => {}, [selectedDate]);
+  useEffect(() => {
+    // 필요한 로직 구현
+  }, [selectedDate]);
useEffect가 필요없는 경우:
-  useEffect(() => {}, [selectedDate]);
Line range hint 14-65: 목업 데이터의 개선이 필요합니다.

현재 목업 데이터에서 몇 가지 개선이 필요한 부분이 있습니다:

모든 항목의 liked 값이 true로 동일합니다

이미지 URL이 모든 항목에서 동일합니다

제목이 모든 항목에서 동일합니다

개발 환경에서의 테스트를 위해 더 다양한 케이스를 포함하도록 데이터를 수정하는 것이 좋겠습니다. 도움이 필요하시다면 다양한 테스트 케이스를 포함한 목업 데이터를 제안해드릴 수 있습니다.
src/components/common/writable-gathering-card/writable-gathering-card.tsx (1)

Line range hint 71-71: 불필요한 NOTE 주석을 제거해주세요.

participants prop이 이미 올바르게 사용되고 있어 "NOTE: participants prop 넘겨줘야함" 주석이 더 이상 필요하지 않습니다.
src/components/common/crew-list/crew-card.tsx (2)
28-36: props 구조분해가 잘 되어있습니다만, 약간의 개선이 가능합니다.

선택적 props(isConfirmed, crewMembers, inWhere)를 마지막에 모아두면 코드 가독성이 더 좋아질 것 같습니다.
export default function CrewCard({
  id,
  title,
  mainLocation,
  subLocation,
  participantCount,
  totalCount,
  imageUrl,
- isConfirmed,
  totalGatheringCount,
+ isConfirmed,
  crewMembers,
  inWhere,
}: CrewCardProps)
64-64: UI 렌더링 최적화를 위한 제안

UI 업데이트가 잘 되었습니다만, 다음과 같은 성능 최적화를 고려해보시면 좋을 것 같습니다:

Image 컴포넌트에 priority 속성 추가를 고려해보세요:
- <Image fill objectFit="cover" alt={title} src={imageUrl} />
+ <Image fill objectFit="cover" alt={title} src={imageUrl} priority />
문자열 보간식을 상수로 분리하면 불필요한 재생성을 방지할 수 있습니다:
+ const gatheringCountText = `현재 ${totalGatheringCount}개의 약속이 개설되어 있습니다.`;

- {`현재 ${totalGatheringCount}개의 약속이 개설되어 있습니다.`}
+ {gatheringCountText}
Also applies to: 71-71, 74-74, 78-78, 87-87, 91-91, 102-102
src/mock/gathering-data.ts (2)
Line range hint 1-484: 타입 정의 추가를 제안합니다.

데이터 구조의 안정성을 높이기 위해 타입 정의를 추가하는 것이 좋겠습니다.
interface CrewMember {
  id: number;
  nickname: string;
  profileImageUrl: string;
}

interface Gathering {
  id: number;
  title: string;
  dateTime: string;
  location: string;
  currentCount: number;
  totalCount: number;
  imageUrl: string;
  liked: boolean;
  crewList?: CrewMember[];
}

interface GatheringResponse {
  data: Gathering[];
  pagination: {
    totalCount: number;
    page: number;
    limit: number;
  };
}

export const gatheringData: GatheringResponse = {
  // 기존 데이터 유지
};
데이터 구조의 일관성 문제가 확인되었습니다.

일부 gathering 객체에서 crewList 필드가 누락되어 있습니다:

id: 5, 10, 12, 13번 객체에는 crewList 필드가 없습니다.

나머지 객체들은 모두 crewList 필드를 포함하고 있습니다.

데이터의 일관성을 위해 다음 중 하나의 방식으로 수정이 필요합니다:

모든 객체에 crewList 필드를 추가하고, 참여자가 없는 경우 빈 배열([])로 설정

또는 crewList 필드가 선택적(optional)임을 명시하는 타입 정의 추가

🔗 Analysis chain

Line range hint 1-484: 데이터 구조의 일관성을 검증해주세요.

일부 gathering 객체에는 crewList가 있고 일부는 없습니다. 이것이 의도된 것인지 확인이 필요합니다.
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:
#!/bin/bash
# Description: 모든 gathering 객체의 crewList 존재 여부 확인

echo "crewList가 없는 gathering 객체 확인:"
ast-grep --pattern 'id: $_,
  title: $_,
  dateTime: $_,
  location: $_,
  currentCount: $_,
  totalCount: $_,
  imageUrl: $_,
  liked: $_,
  $$$
}' src/mock/gathering-data.ts | grep -v "crewList"
Length of output: 265

Script:
#!/bin/bash
# 모든 gathering 객체의 구조를 확인하기 위한 스크립트
echo "gathering 객체들의 구조 확인:"
rg -U "id: \d+.*?}," src/mock/gathering-data.ts --multiline | while read -r line; do
    if echo "$line" | grep -q "crewList"; then
        echo "crewList 있음: $(echo "$line" | grep -o "id: [0-9]\+")"
    else
        echo "crewList 없음: $(echo "$line" | grep -o "id: [0-9]\+")"
    fi
done
Length of output: 129

Script:
#!/bin/bash
# gathering 데이터 객체에서 crewList가 없는 항목 찾기
echo "crewList가 없는 gathering 항목:"
cat src/mock/gathering-data.ts | grep -A 10 "id: [0-9]" | grep -B 10 "liked: " | grep -v "crewList" | grep "id: "

echo -e "\ncrewList가 있는 gathering 항목:"
cat src/mock/gathering-data.ts | grep -A 10 "id: [0-9]" | grep -B 10 "crewList" | grep "id: "
Length of output: 714
src/types/crew-card.d.ts (2)
23-23: 'profileImageUrl'의 타입 명확화 제안

CrewMember 인터페이스에서 profileImageUrl은 선택적 속성으로 정의되어 있습니다. 그러나 데이터가 존재하지 않을 경우 명시적으로 null을 반환하는 것이 명확성을 높일 수 있습니다.

변경 사항:
-  profileImageUrl?: string;
+  profileImageUrl: string | null;
13-14: 필드 배치 순서 일관성 제안

participantCount와 totalCount의 필드 순서를 다른 인터페이스와 일치시키면 가독성이 향상됩니다. 예를 들어, CrewDetail 인터페이스에서는 이 두 필드의 순서가 반대입니다.
src/components/common/crew-list/crew-card-list.tsx (3)

13-16: inWhere의 타입 정의를 개선할 것을 제안합니다

현재 MainCrewCardListProps에서 inWhere?: undefined;로 정의되어 있습니다. inWhere를 생략하거나 inWhere?: never;로 설정하면 타입 안전성을 높이고 코드 가독성을 향상시킬 수 있습니다.

32-35: crewDataList 계산 로직을 간소화할 수 있습니다

crewDataList를 계산하는 로직에서 중복된 코드가 발생하고 있습니다. inWhere에 따른 타입을 동적으로 처리하여 코드 중복을 줄이고 가독성을 개선할 수 있습니다.

49-50: 목데이터 업데이트를 통해 undefined 문제를 사전에 해결하세요

주석에서 언급하신 대로 데이터 이름 변경으로 인해 개발 환경에서 undefined가 발생할 수 있습니다. 목데이터를 최신 데이터 구조에 맞게 업데이트하면 이러한 문제를 방지하고 더 원활한 개발이 가능합니다.

목데이터 업데이트에 도움이 필요하시면 제가 지원해드릴 수 있습니다.
src/mock/crew-data.ts (1)
19-19: crewMember를 복수형 crewMembers로 변경을 제안합니다.

배열을 나타내는 속성이므로, crewMembers로 이름을 변경하면 가독성이 향상됩니다.

수정을 위한 변경 사항은 다음과 같습니다:
 interface CrewDataItem {
   // ...
-  crewMember: CrewMember[];
+  crewMembers: CrewMember[];
 }
 
 export const crewData: CrewData = {
   data: [
     {
       id: 1,
       // ...
-      crewMember: [
+      crewMembers: [
         // 회원 데이터
       ],
     },
     // 나머지 데이터 항목에서도 동일하게 적용
   ],
 };
Also applies to: 29-29, 74-74, 149-149, 170-170, 191-191, 212-212, 287-287, 332-332, 407-407, 440-440, 461-461

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 19865ab and 5c55f46.

📒 Files selected for processing (38)

.vscode/settings.json (1 hunks)
next.config.mjs (1 hunks)
public/assets/images/crew-sample/index.tsx (1 hunks)
public/assets/images/gathering-sample/index.tsx (1 hunks)
src/_apis/crew/get-crew-list.ts (2 hunks)
src/_apis/detail/get-crew-detail.ts (1 hunks)
src/_apis/detail/get-gathering-list.ts (1 hunks)
src/_apis/getUser.ts (0 hunks)
src/_queries/crew-queries.tsx (1 hunks)
src/_queries/useGetUserQuery.ts (0 hunks)
src/app/(crew)/api-test/page.tsx (0 hunks)
src/app/(crew)/crew/_components/gathering-detail-modal/gathering-detail-modal.stories.tsx (3 hunks)
src/app/(crew)/crew/_components/gathering-detail-modal/presenter.tsx (3 hunks)
src/app/(crew)/crew/detail/[id]/page.tsx (1 hunks)
src/app/(crew)/my-crew/page.tsx (3 hunks)
src/app/(crew)/my-gathering/creation/page.tsx (4 hunks)
src/app/(crew)/my-gathering/participation/page.tsx (3 hunks)
src/app/(crew)/page.tsx (2 hunks)
src/components/common/crew-list/crew-card-list.stories.tsx (2 hunks)
src/components/common/crew-list/crew-card-list.tsx (2 hunks)
src/components/common/crew-list/crew-card.tsx (4 hunks)
src/components/common/crew-list/detail-crew-card.stories.tsx (1 hunks)
src/components/common/crew-list/detail-crew-card.tsx (6 hunks)
src/components/common/crew-list/profiles.tsx (1 hunks)
src/components/common/gathering-card/container.tsx (2 hunks)
src/components/common/gathering-card/gathering-card.stories.tsx (5 hunks)
src/components/common/gathering-card/scheduled-gathering-card/container.tsx (2 hunks)
src/components/common/gathering-card/scheduled-gathering-card/presenter.tsx (3 hunks)
src/components/common/gathering-card/scheduled-gathering-card/scheduled-gathering.stories.tsx (2 hunks)
src/components/common/writable-gathering-card/writable-gathering-card.tsx (1 hunks)
src/components/gathering-list/gathering-card-carousel.tsx (1 hunks)
src/components/gathering-list/gathering-carousel.stories.tsx (3 hunks)
src/mock/crew-data.ts (10 hunks)
src/mock/gathering-data.ts (16 hunks)
src/types/create-crew.d.ts (1 hunks)
src/types/crew-card.d.ts (1 hunks)
src/types/gathering-data.d.ts (2 hunks)
src/types/writable-gathering-card.d.ts (1 hunks)

💤 Files with no reviewable changes (3)

src/_apis/getUser.ts
src/_queries/useGetUserQuery.ts
src/app/(crew)/api-test/page.tsx

✅ Files skipped from review due to trivial changes (4)

next.config.mjs
public/assets/images/crew-sample/index.tsx
public/assets/images/gathering-sample/index.tsx
src/types/create-crew.d.ts

🔇 Additional comments (48)

src/_apis/detail/get-gathering-list.ts (2)

2-5: 타입 표준화가 잘 이루어졌습니다.

커스텀 GatheringList 타입에서 표준화된 GatheringType으로의 마이그레이션이 깔끔하게 처리되었습니다.

4-5: 타입 호환성 검증이 필요합니다.

백엔드 API 응답과 GatheringType의 구조가 일치하는지 확인이 필요합니다.

src/_apis/detail/get-crew-detail.ts (1)

1-2: 타입 정의 중앙화 개선이 잘 이루어졌습니다!

타입 정의를 중앙 집중화하여 코드의 일관성과 유지보수성이 향상되었습니다.

src/types/writable-gathering-card.d.ts (1)

19-19: 백엔드 API 응답 타입과 일치하는지 확인이 필요합니다.

profileImageUrl을 선택적 필드로 변경한 것이 적절해 보입니다. 하지만 이 변경사항이 실제 백엔드 API 응답과 일치하는지 확인이 필요합니다.

백엔드 API 응답 구조를 확인하기 위해 다음 스크립트를 실행해보세요:

✅ Verification successful

profileImageUrl 타입 변경이 적절합니다

코드베이스 분석 결과, 다음과 같은 이유로 profileImageUrl을 선택적 필드로 변경한 것이 적절합니다:

auth.ts와 user.d.ts에서는 필수 필드로 사용되지만, crew-card.d.ts에서도 이미 선택적 필드로 정의되어 있어 일관성이 있습니다.
WritableGatheringCardInform 타입의 participants 배열에서 사용되는 ParticipantType은 간소화된 사용자 정보를 표현하는 것으로, 프로필 이미지가 없는 경우를 허용하는 것이 자연스럽습니다.
이는 프론트엔드의 유연성을 높이고 백엔드 API 응답과의 타입 불일치 문제를 해결하는데 도움이 됩니다.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# API 응답 타입 정의를 검색
rg -t ts "type.*Response.*=.*{" --glob "src/types/**"

Length of output: 159

Script:

#!/bin/bash
# Search for API response type definitions with fixed regex
rg -t ts "type.*Response.*\{" --glob "src/types/**"

# Search for files containing profileImageUrl
rg -t ts "profileImageUrl" --glob "src/types/**"

# Search for any API related type definitions
fd -e ts -e d.ts . src/types/ --exec grep -l "API\|Response\|Request"

# Look for any swagger or API schema definitions
fd "api|swagger|schema" . src/types/

Length of output: 897

Script:

#!/bin/bash
# Check the content of auth.ts and user.d.ts where profileImageUrl is required
cat src/types/auth.ts src/types/user.d.ts

# Check the content of gathering APIs
cat src/_apis/gathering/gathering-apis.tsx

# Check the content of WritableGatheringCardInformResponse
rg -A 10 "WritableGatheringCardInformResponse" src/types/writable-gathering-card.d.ts

Length of output: 1308

Script:

#!/bin/bash
# Check the full content of writable-gathering-card.d.ts to see ParticipantType definition
cat src/types/writable-gathering-card.d.ts

# Check if there are any API response handlers or components using this type
rg -t tsx "ParticipantType" src/

Length of output: 559

src/_queries/crew-queries.tsx (3)

1-1: 타입 변경이 적절히 이루어졌습니다.

백엔드 타입과의 일관성을 위해 CrewCardInform에서 MainCrewList로 변경한 것이 적절해 보입니다.

17-17: 페이지네이션 로직이 올바르게 수정되었습니다.

hasNext 프로퍼티를 사용하도록 변경되었으며, 페이지네이션 로직은 여전히 올바르게 동작할 것으로 보입니다.

10-10: 프로퍼티 이름 변경에 따른 영향도 확인 필요

hasNextPage에서 hasNext로의 변경이 다른 컴포넌트에도 영향을 미칠 수 있습니다.

다음 스크립트로 관련 코드를 확인해보세요:

src/_apis/crew/get-crew-list.ts (3)

1-2: 타입 임포트 변경이 적절히 이루어졌습니다.

CrewCardInform에서 MainCrewList로의 타입 변경이 일관성 있게 적용되었습니다.

4-4: 반환 타입이 올바르게 업데이트되었습니다.

Promise로의 타입 변경이 적절합니다.

18-21: 변수명 변경이 의미를 더 명확하게 합니다.

hasNextPage에서 hasNext로의 변경이 적절합니다. 하지만 페이지네이션 로직에 대한 추가 검증이 필요할 수 있습니다.

✅ Verification successful

페이지네이션 변수명 변경이 일관성을 해치지 않습니다

코드베이스 분석 결과, hasNext와 hasNextPage는 각각 다른 컨텍스트에서 일관되게 사용되고 있습니다:

MainCrewListResponse와 MyCrewListResponse 타입에서는 hasNext 사용
리뷰와 모임 관련 타입에서는 hasNextPage 사용

따라서 get-crew-list.ts에서 hasNext를 사용한 것은 크루 관련 타입과의 일관성을 유지하는 적절한 변경입니다.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# 페이지네이션 로직이 일관되게 적용되었는지 확인
rg -l "hasNextPage|hasNext" --type typescript

Length of output: 82

Script:

#!/bin/bash
# Search for pagination-related variables in all files
rg -l "hasNextPage|hasNext" 

# Get more context around the matches
rg "hasNextPage|hasNext" -B 2 -A 2

Length of output: 6234

src/types/gathering-data.d.ts (1)

48-48: 프로퍼티 이름 일관성 개선 확인

GatheringCardProps 인터페이스의 liked 프로퍼티 이름이 다른 타입 정의들과 일관성 있게 변경되었습니다.

src/components/common/crew-list/crew-card-list.stories.tsx (2)

5-5: 타입 임포트 변경이 적절합니다.

백엔드 타입과의 일관성을 위해 MainCrewListResponse 타입으로 변경한 것이 적절해 보입니다.

32-32: 타입 파라미터 업데이트가 적절하나 검증이 필요합니다.

useInfiniteScroll 훅의 타입 파라미터를 MainCrewListResponse로 변경한 것이 적절해 보입니다. 다만, 이 변경이 다른 컴포넌트에도 영향을 미칠 수 있으므로 확인이 필요합니다.

다른 컴포넌트에서의 사용을 확인하기 위해 다음 스크립트를 실행하세요:

✅ Verification successful

MainCrewListResponse 타입 파라미터 사용이 적절합니다

useInfiniteScroll 훅의 타입 파라미터를 MainCrewListResponse로 변경한 것이 적절합니다. 다음과 같은 이유로 검증되었습니다:

MainCrewListResponse 타입이 data와 hasNext 필드를 포함하고 있어 무한 스크롤 구현에 필요한 데이터 구조와 일치합니다.
해당 타입은 src/types/crew-card.d.ts에 명확하게 정의되어 있습니다.
동일한 패턴이 src/app/(crew)/page.tsx에서도 사용되고 있어 일관성이 유지됩니다.
다른 컴포넌트들은 각자의 용도에 맞는 적절한 타입 파라미터(ReviewInformResponse, WritableGatheringCardInformResponse 등)를 사용하고 있어 영향을 받지 않습니다.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: useInfiniteScroll 훅의 사용 패턴을 검색하여 타입 변경이 필요한 다른 컴포넌트가 있는지 확인

# useInfiniteScroll 사용 패턴 검색
echo "useInfiniteScroll 훅 사용 검색:"
rg "useInfiniteScroll[<]" -A 2

# CrewCardInformResponse 타입 사용 검색
echo -e "\nCrewCardInformResponse 타입 사용 검색:"
rg "CrewCardInformResponse"

Length of output: 2786

Script:

#!/bin/bash
# Let's check the implementation and type definition of useInfiniteScroll
echo "Checking useInfiniteScroll implementation:"
ast-grep --pattern 'function useInfiniteScroll<$_>($_) { $$$ }'

echo -e "\nChecking MainCrewListResponse type definition:"
rg "type MainCrewListResponse" -A 5

echo -e "\nChecking imports of MainCrewListResponse:"
rg "import.*MainCrewListResponse"

Length of output: 757

Script:

#!/bin/bash
# Let's check the type definition in crew-card.ts
echo "Checking crew-card.ts type definitions:"
rg -A 10 "export type MainCrewListResponse" src/types/crew-card.ts

# Let's also check the usage context of useInfiniteScroll with MainCrewListResponse
echo -e "\nChecking usage context:"
rg -B 2 -A 2 "useInfiniteScroll<MainCrewListResponse>"

Length of output: 1109

Script:

#!/bin/bash
# Let's check the types directory for crew-card type definitions
echo "Finding crew-card type definition file:"
fd "crew-card.d.ts|crew-card.types.ts" src/

echo -e "\nChecking all files that might contain MainCrewListResponse type definition:"
fd . src/ -t f -x grep -l "MainCrewListResponse"

echo -e "\nChecking useGetCrewQuery implementation:"
rg -A 5 "useGetCrewQuery"

Length of output: 3957

Script:

#!/bin/bash
# Let's check the MainCrewListResponse type definition
echo "Checking MainCrewListResponse type definition:"
cat src/types/crew-card.d.ts

# Let's also check the useInfiniteScroll hook implementation
echo -e "\nChecking useInfiniteScroll hook implementation:"
fd useInfiniteScroll.ts src/hooks/ -x cat {}

Length of output: 2099

src/components/common/crew-list/profiles.tsx (2)

1-2: 타입 임포트가 올바르게 수정되었습니다.

백엔드 타입과의 일관성을 위해 CrewMember 타입으로 변경한 것이 적절해 보입니다.

4-7: 타입 변경의 영향도를 확인해주세요.

ProfilesProps 인터페이스의 profiles 타입이 CrewMember[]로 변경되었습니다. 이는 breaking change가 될 수 있으므로, 이 컴포넌트를 사용하는 모든 곳에서 새로운 타입이 올바르게 적용되었는지 확인이 필요합니다.

다음 스크립트를 실행하여 Profiles 컴포넌트의 사용처를 확인해주세요:

✅ Verification successful

Let's check the actual usage in those files to understand how the Profiles component is being used.

Let's check what type was previously used for the profiles prop before this change.

From the git history, we can see the type evolution. Let's check the CrewMember type definition with a different command.

타입 변경이 안전하게 적용되었습니다

Git 히스토리와 현재 코드베이스 분석 결과:

ProfilesProps의 profiles 타입이 CrewMemberList[]에서 CrewMember[]로 변경되었습니다
이 컴포넌트를 사용하는 모든 파일(writable-gathering-card.tsx, detail-crew-card.tsx, crew-card.tsx)에서 이미 CrewMember 타입을 올바르게 임포트하고 사용하고 있습니다
CrewMemberList 타입은 더 이상 코드베이스 어디에서도 사용되지 않습니다
CrewMember 인터페이스는 src/types/crew-card.d.ts에 명확하게 정의되어 있습니다

따라서 이 타입 변경은 안전하게 이루어졌으며, 추가 수정이 필요하지 않습니다.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Profiles 컴포넌트의 사용처 확인
echo "Profiles 컴포넌트 사용처 확인 중..."
rg -l "Profiles.*profiles=" src/

Length of output: 268

Script:

#!/bin/bash
# Check how Profiles component is used in the found files
echo "=== writable-gathering-card.tsx ==="
rg "Profiles.*profiles=" -A 2 src/components/common/writable-gathering-card/writable-gathering-card.tsx

echo -e "\n=== detail-crew-card.tsx ==="
rg "Profiles.*profiles=" -A 2 src/components/common/crew-list/detail-crew-card.tsx

echo -e "\n=== crew-card.tsx ==="
rg "Profiles.*profiles=" -A 2 src/components/common/crew-list/crew-card.tsx

# Also check the type imports in these files
echo -e "\n=== Checking CrewMember type imports ==="
rg "CrewMember" src/components/common/writable-gathering-card/writable-gathering-card.tsx src/components/common/crew-list/detail-crew-card.tsx src/components/common/crew-list/crew-card.tsx

Length of output: 1430

Script:

#!/bin/bash
# Check git history for the ProfilesProps interface
git log -p src/components/common/crew-list/profiles.tsx | grep -A 5 "interface ProfilesProps"

# Also check the CrewMember type definition
echo -e "\n=== CrewMember type definition ==="
rg -t typescript "type CrewMember" -A 5 src/types/
rg -t typescript "interface CrewMember" -A 5 src/types/

Length of output: 1472

Script:

#!/bin/bash
# Check CrewMember type definition without specifying typescript
echo "=== CrewMember type definition ==="
rg "type CrewMember|interface CrewMember" -A 5 src/

# Check if there are any imports of CrewMemberList type
echo -e "\n=== CrewMemberList type usage ==="
rg "CrewMemberList" src/

Length of output: 727

src/components/common/crew-list/detail-crew-card.stories.tsx (1)

Line range hint 22-32: 프로퍼티 이름 변경이 적절합니다.

camelCase 네이밍 컨벤션을 따르도록 CrewMembers에서 crewMembers로 변경한 것이 적절합니다. 이는 코드베이스 전반의 일관성을 향상시킵니다.

src/app/(crew)/my-crew/page.tsx (1)

8-8: 타입 변경이 전체 애플리케이션에 미치는 영향 확인 필요

백엔드 타입과의 일관성을 위해 MyCrewListResponse 타입으로 변경한 것은 적절해 보입니다. 하지만 이 변경이 다른 컴포넌트나 기능에 영향을 미칠 수 있습니다.

✅ Verification successful

Let's check both the new type usage and related type definitions to better understand the impact of this change.

Let's examine the type definition and its usage in the crew-card-list component to ensure the type change is properly implemented.

MyCrewListResponse 타입 변경은 안전하게 구현되어 있습니다

CrewCardList 컴포넌트가 이미 MyCrewListResponse와 MainCrewListResponse 타입을 모두 지원하도록 설계되어 있으며, 타입 가드를 통해 안전하게 처리되고 있습니다. 이전 타입인 CrewCardInformResponse는 더 이상 코드베이스에서 사용되지 않으므로 타입 변경으로 인한 부작용은 없을 것으로 판단됩니다.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: 이전 타입 사용 여부 확인
rg "CrewCardInformResponse"

Length of output: 27

Script:

#!/bin/bash
# Check for any references to MyCrewListResponse type
rg "MyCrewListResponse"

# Search for any crew-related type definitions
fd "types" --type f --exec rg -l "crew|Crew"

Length of output: 498

Script:

#!/bin/bash
# Check the definition of MyCrewListResponse type
cat src/types/crew-card.d.ts

# Check the implementation of crew-card-list component
cat src/components/common/crew-list/crew-card-list.tsx

Length of output: 3937

src/app/(crew)/my-gathering/participation/page.tsx (1)

24-24: 타입 변경이 올바르게 적용되었습니다

isLiked에서 liked로의 프로퍼티 이름 변경이 백엔드 타입과의 일관성을 위해 올바르게 적용되었습니다.

Also applies to: 37-37, 50-50

src/components/common/gathering-card/gathering-card.stories.tsx (3)

22-22: argTypes에서 속성명 변경이 올바르게 적용되었습니다.

isLiked에서 liked로의 속성명 변경이 백엔드 타입과의 일관성을 개선했습니다.

40-40: 스토리 정의에서 속성명이 일관되게 변경되었습니다.

모든 스토리 정의(Default, NotLiked, PastEvent, LikedEvent)에서 isLiked에서 liked로의 속성명 변경이 일관되게 이루어졌습니다. 이는 컴포넌트의 타입 일관성을 향상시킵니다.

Also applies to: 54-54, 68-68, 82-82

Line range hint 1-84: 타입 수정과 관련된 추가 검토 사항

이 변경사항이 다른 컴포넌트나 페이지에서 GatheringCard를 사용하는 곳에도 영향을 미칠 수 있습니다.

다음 스크립트를 실행하여 GatheringCard 컴포넌트의 사용처를 확인하겠습니다:

src/components/common/gathering-card/container.tsx (1)

7-7: 타입 정의 개선이 잘 이루어졌습니다!

GatheringType을 확장하여 인터페이스를 정의한 것이 코드 중복을 줄이고 타입 안정성을 높이는 좋은 방법입니다.

Also applies to: 10-12

src/components/common/gathering-card/scheduled-gathering-card/container.tsx (1)

36-38: 더미 데이터의 타입 변경이 적절합니다.

백엔드 타입과 일치하도록 아래와 같이 속성명이 변경되었습니다:

isLiked → liked
isGatherCaptain → gatheringCaptain
isParticipant → participant

src/app/(crew)/my-gathering/creation/page.tsx (1)

24-24: 타입 일관성 개선이 확인되었습니다.

백엔드 타입과의 일관성을 위해 isLiked에서 liked로 속성명이 변경된 것이 적절하게 반영되었습니다.

Also applies to: 37-37, 50-50, 63-63

src/components/common/writable-gathering-card/writable-gathering-card.tsx (2)

45-45: 프로퍼티 이름 변경이 올바르게 적용되었습니다.

imageUrl에서 profileImageUrl로의 프로퍼티 이름 변경이 백엔드 타입과 일치하도록 잘 수정되었습니다. 이는 PR의 주요 목적인 타입 일관성 개선에 부합합니다.

Line range hint 61-61: "위치" 텍스트에 대한 실제 데이터 구현이 필요합니다.

현재 하드코딩된 "위치" 텍스트가 있습니다. 실제 위치 데이터를 표시하도록 구현이 필요해 보입니다.

위치 데이터 구현에 도움이 필요하시다면 말씀해 주세요.

.vscode/settings.json (1)

64-64: 맞춤법 검사 사전에 추가된 단어가 적절합니다.

"CODEIT"와 "pretendard"를 맞춤법 검사 사전에 추가한 것이 적절해 보입니다. "CODEIT"는 프로젝트 이름이고, "pretendard"는 프로젝트에서 사용되는 폰트명으로 추정됩니다.

src/components/common/gathering-card/scheduled-gathering-card/presenter.tsx (2)

39-39: 구조 분해 할당이 올바르게 수정되었습니다.

인터페이스 변경사항이 정확하게 반영되었습니다.

100-100: ⚠️ Potential issue

LikeBtn 컴포넌트의 prop 이름이 일치하지 않습니다.

데이터 객체에서는 liked로 변경되었지만, LikeBtn 컴포넌트에서는 여전히 isLiked를 prop 이름으로 사용하고 있습니다. 일관성을 위해 LikeBtn 컴포넌트도 수정이 필요할 수 있습니다.

#!/bin/bash
# LikeBtn 컴포넌트의 props 타입 정의 확인
ast-grep --pattern 'interface $name {
  $$$
  isLiked: $_
  $$$
}'

src/app/(crew)/page.tsx (2)

14-14: 타입 임포트가 올바르게 변경되었습니다.

백엔드 타입과의 일관성을 위해 CrewCardInformResponse에서 MainCrewListResponse로 변경된 것이 확인됩니다.

25-25: 타입 변경에 따른 데이터 구조 검증이 필요합니다.

useInfiniteScroll 훅의 타입 파라미터가 MainCrewListResponse로 변경되었습니다. 백엔드 API 응답과 새로운 타입이 정확히 일치하는지 확인이 필요합니다.

다음 스크립트로 관련 타입 정의들을 확인할 수 있습니다:

✅ Verification successful

타입 변경이 적절하게 이루어졌습니다.

MainCrewListResponse 타입이 다음과 같이 명확하게 정의되어 있으며, API 응답 처리 로직과 일관성 있게 사용되고 있음을 확인했습니다:

src/types/crew-card.d.ts에 타입이 명확하게 정의됨
src/_apis/crew/get-crew-list.ts에서 API 응답 타입으로 올바르게 사용됨
이전 타입인 CrewCardInformResponse에 대한 참조가 없어 깔끔하게 마이그레이션됨

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: 타입 정의와 사용처 확인

# MainCrewListResponse 타입 정의 확인
echo "=== MainCrewListResponse 타입 정의 ==="
rg -t typescript "type MainCrewListResponse" 

# API 응답 타입 사용 확인
echo -e "\n=== API 응답 타입 사용 확인 ==="
rg -t typescript "MainCrewListResponse" 

# 이전 타입 참조 검색
echo -e "\n=== 이전 타입(CrewCardInformResponse) 참조 확인 ==="
rg -t typescript "CrewCardInformResponse"

Length of output: 478

Script:

#!/bin/bash
# Description: 타입 정의와 사용처 확인 (수정된 버전)

# MainCrewListResponse 타입 정의 확인
echo "=== MainCrewListResponse 타입 정의 ==="
rg "type MainCrewListResponse" 

# API 응답 타입 사용 확인
echo -e "\n=== API 응답 타입 사용 확인 ==="
rg "MainCrewListResponse" -A 2

# 이전 타입 참조 검색
echo -e "\n=== 이전 타입(CrewCardInformResponse) 참조 확인 ==="
rg "CrewCardInformResponse"

# 관련 타입 파일 검색
echo -e "\n=== 타입 정의 파일 검색 ==="
fd "types?.ts" --type f

Length of output: 2555

Script:

#!/bin/bash
# MainCrewList 타입 정의와 구조 확인
echo "=== MainCrewList 타입 정의 확인 ==="
rg "interface MainCrewList" -A 10

# crew-card.d.ts 파일 전체 내용 확인
echo -e "\n=== crew-card.d.ts 파일 내용 ==="
fd "crew-card.d.ts" -x cat {}

# API 응답 처리 로직 확인
echo -e "\n=== API 응답 처리 로직 확인 ==="
rg -A 5 "getCrewList.*Promise"

Length of output: 2544

src/components/common/crew-list/crew-card.tsx (1)

7-7: 타입 정의가 개선되었습니다! 👍

백엔드 데이터 구조와 일치하도록 타입이 잘 수정되었으며, 프로퍼티 이름이 더 명확해졌습니다. 특히:

name → title
location → mainLocation
detailedLocation → subLocation
capacity → totalCount
thumbnail → imageUrl

등의 변경이 의미를 더 잘 전달합니다.

Also applies to: 14-22

src/components/gathering-list/gathering-card-carousel.tsx (2)

6-6: 타입 임포트 변경이 적절합니다.

새로운 GatheringType 임포트가 올바르게 추가되었습니다.

11-11: 타입 정의 변경이 백엔드 타입과 일치합니다.

GatheringDataType[]에서 GatheringType[]으로의 변경이 PR의 목적에 부합하며, 백엔드 타입과의 일관성을 개선했습니다.

타입 사용의 일관성을 확인하기 위해 다음 스크립트를 실행합니다:

✅ Verification successful

Let me generate the final response since I have sufficient information from the executed scripts.

타입 변경이 일관되게 적용되었습니다

GatheringDataType은 코드베이스에서 완전히 제거되었으며, GatheringType이 다음 위치에서 일관되게 사용되고 있습니다:

타입 정의: src/types/gathering-data.d.ts
API 호출: src/_apis/detail/get-gathering-list.ts
컴포넌트:
- gathering-card-carousel.tsx
- gathering-list.tsx
- gathering-card/container.tsx

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: 기존 GatheringDataType 사용 여부 확인 및 새로운 GatheringType 사용 검증

# Test 1: 기존 GatheringDataType이 완전히 제거되었는지 확인
echo "기존 GatheringDataType 사용 검사:"
rg "GatheringDataType"

# Test 2: 새로운 GatheringType이 일관되게 사용되는지 확인
echo -e "\n새로운 GatheringType 사용 검사:"
rg "GatheringType"

Length of output: 1263

src/app/(crew)/crew/_components/gathering-detail-modal/gathering-detail-modal.stories.tsx (4)

67-69: 프로퍼티 이름 변경이 적절하게 이루어졌습니다.

백엔드 타입과의 일관성을 위해 불리언 프로퍼티 이름이 적절하게 변경되었습니다:

isLiked → liked
isGatherCaptain → gatheringCaptain
isParticipant → participant

109-111: ModalWithCaptain의 프로퍼티 값이 역할에 맞게 설정되었습니다.

캡틴 역할을 나타내는 스토리에서 gatheringCaptain과 participant가 true로 적절하게 설정되어 있습니다.

151-153: ModalWithCrew의 프로퍼티 값이 적절합니다.

일반 크루원의 상태를 나타내는 스토리에서 participant만 true로 설정되어 있어 의도된 상태를 잘 표현하고 있습니다.

Line range hint 1-193: 타입 정의 파일 업데이트 확인이 필요합니다.

프로퍼티 이름 변경이 관련 타입 정의 파일에도 반영되었는지 확인이 필요합니다.

✅ Verification successful

타입 정의가 올바르게 업데이트되어 있습니다.

src/types/gathering-data.d.ts 파일에서 새로운 프로퍼티 이름들이 이미 정의되어 있음을 확인했습니다:

liked
gatheringCaptain
participant
participants

이전 프로퍼티 이름들(isLiked, isGatherCaptain, isParticipant)은 타입 정의 파일에서 발견되지 않았으며, 새로운 이름으로 올바르게 업데이트되어 있습니다.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: 관련된 타입 정의 파일에서 이전 프로퍼티 이름이 남아있는지 확인

# Test: Search for old property names in type definition files
echo "Checking for old property names in type definitions..."
rg -t typescript "isLiked|isGatherCaptain|isParticipant" "src/types/"

Length of output: 223

Script:

#!/bin/bash
# Let's try searching in all files without type restriction
echo "Searching for old property names across the codebase..."
rg "isLiked|isGatherCaptain|isParticipant"

# Also search for the new property names to understand the changes
echo -e "\nSearching for new property names..."
rg "liked|gatheringCaptain|participant"

# Let's also check for any type definitions specifically
echo -e "\nSearching for type definitions..."
fd "\.d\.ts$|\.types\.ts$|types\.tsx?$"

Length of output: 13237

src/app/(crew)/crew/_components/gathering-detail-modal/presenter.tsx (3)

Line range hint 123-131: 참여자 상태 확인 로직이 올바르게 수정되었습니다.

isParticipant에서 participant로의 변경이 백엔드 타입과 일치하도록 적절히 수정되었습니다.

Line range hint 132-140: 참여자 및 모임장 상태 확인 로직이 올바르게 수정되었습니다.

isParticipant와 isGatherCaptain에서 각각 participant와 gatheringCaptain으로의 변경이 백엔드 타입과 일치하도록 적절히 수정되었습니다.

Line range hint 141-149: 모임장 상태 확인 로직이 올바르게 수정되었습니다.

isGatherCaptain에서 gatheringCaptain으로의 변경이 백엔드 타입과 일치하도록 적절히 수정되었습니다.

다른 컴포넌트에서도 동일한 프로퍼티 이름이 일관되게 사용되는지 확인하겠습니다:

✅ Verification successful

프로퍼티 이름이 전체 코드베이스에서 일관되게 변경되었습니다.

타입 정의와 실제 사용처를 검토한 결과:

src/types/gathering-data.d.ts에서 gatheringCaptain과 participant 프로퍼티가 올바르게 정의되어 있습니다.
모든 컴포넌트에서 새로운 프로퍼티명을 일관되게 사용하고 있습니다.
이전 프로퍼티명(isGatherCaptain, isParticipant)은 오직 mock 데이터에서만 발견되었으며, 실제 코드에서는 사용되지 않습니다.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: 타입 변경이 일관되게 적용되었는지 확인

# Test 1: 이전 프로퍼티명 사용 여부 확인
echo "Checking for old property names..."
rg "isParticipant|isGatherCaptain" --type tsx

# Test 2: 새로운 프로퍼티명 사용 확인
echo "Checking for new property names..."
rg "participant:|gatheringCaptain:" --type tsx

Length of output: 310

Script:

#!/bin/bash
# Description: 타입 변경이 일관되게 적용되었는지 확인

# Test 1: 이전 프로퍼티명 사용 여부 확인
echo "Checking for old property names..."
rg "isParticipant|isGatherCaptain"

# Test 2: 새로운 프로퍼티명 사용 확인
echo "Checking for new property names..."
rg "participant|gatheringCaptain"

# Test 3: 관련 타입 정의 확인
echo "Checking type definitions..."
fd -e ts -e tsx | xargs rg "type.*Gathering|interface.*Gathering" -A 5

Length of output: 23929

src/components/common/crew-list/detail-crew-card.tsx (3)

9-9: 타입 변경 및 프로퍼티 이름 수정이 적절합니다.

타입을 CrewMember로 변경하고 프로퍼티 이름을 camelCase로 수정한 것이 코드의 일관성을 높였습니다.

Also applies to: 23-23, 36-36

130-131: Profiles 컴포넌트의 타입 호환성 확인이 필요합니다.

crewMembers를 Profiles 컴포넌트에 전달하는 부분이 새로운 타입과 호환되는지 확인해주세요.

✅ Verification successful

Let me check the type of crewMembers in the component to verify type compatibility.

타입 호환성이 확인되었습니다

Profiles 컴포넌트는 CrewMember[] 타입의 profiles prop을 예상하고 있으며, 전달되는 crewMembers는 동일한 CrewMember 인터페이스를 따르고 있어 타입이 정확히 일치합니다. 추가적인 변경이 필요하지 않습니다.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check Profiles component prop types
ast-grep --pattern 'interface ProfilesProps {
  $$$
  profiles: $_
  $$$
}'

Length of output: 348

Script:

#!/bin/bash
# Check the type of crewMembers in detail-crew-card.tsx
ast-grep --pattern 'const crewMembers = $_'

# Also check CrewMember type definition
ast-grep --pattern 'type CrewMember = $_'
ast-grep --pattern 'interface CrewMember {
  $$$
}'

Length of output: 632

Line range hint 64-98: 주석 처리된 메뉴 로직에 대한 명확한 계획이 필요합니다.

큰 섹션의 코드를 주석 처리하는 것은 바람직하지 않습니다. 다음 중 하나의 방법으로 처리하는 것이 좋습니다:

임시 기능 제거가 맞다면 코드를 완전히 삭제하고 git 히스토리에 보존
향후 구현 예정이라면 구체적인 TODO 설명과 일정 추가

src/mock/gathering-data.ts (1)

12-12: 속성 이름 변경이 일관되게 적용되었습니다.

isLiked에서 liked로의 변경이 모든 데이터 항목에 걸쳐 일관되게 적용되었으며, 백엔드 타입과의 일치성을 개선했습니다.

Also applies to: 55-55, 80-80, 92-92, 135-135, 146-146, 189-189, 208-208, 233-233, 276-276, 287-287, 330-330, 341-341, 352-352, 395-395, 438-438

src/components/common/crew-list/crew-card-list.tsx (1)

13-16: 변경된 타입 정의에 따른 영향 범위를 확인하세요

CrewCardListProps의 타입 정의가 수정되었으므로, 이 타입을 사용하는 다른 부분에서 타입 호환성이 유지되는지 확인하는 것이 중요합니다.

다음 스크립트를 통해 CrewCardListProps를 사용하는 곳을 검색하여 잠재적인 타입 오류를 확인할 수 있습니다:

Also applies to: 19-23

✅ Verification successful

Let me gather more context about the changes and their impact.

Let me check how these types are being used in the component and if there are any other related files.

Let me check the type definitions and their usage in the related files.

타입 정의 변경이 올바르게 처리되었습니다

타입 변경이 다음과 같이 안전하게 처리되었음을 확인했습니다:

MainCrewCardListProps와 MyCrewCardListProps가 명확하게 구분되어 정의되었습니다.
CrewCardListProps 유니온 타입이 두 인터페이스를 올바르게 결합합니다.
CrewCardList 컴포넌트에서 inWhere 값에 따라 적절한 타입 분기 처리가 이루어지고 있습니다.
실제 사용처인 메인 페이지(page.tsx)와 마이크루 페이지(my-crew/page.tsx)에서도 각각의 용도에 맞게 올바른 props를 전달하고 있습니다.

따라서 타입 정의 변경으로 인한 추가적인 수정이 필요하지 않습니다.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: `CrewCardListProps`의 사용처를 검색하여 타입 호환성을 확인합니다.

# Test: `CrewCardListProps`를 사용하는 파일을 검색합니다.
# Expect: 모든 사용처에서 새로운 타입 정의를 올바르게 반영하고 있어야 합니다.
rg 'CrewCardListProps'

Length of output: 506

Script:

#!/bin/bash
# Get the content of the crew-card-list.tsx file to understand the type definitions and their usage
cat src/components/common/crew-list/crew-card-list.tsx

Length of output: 2841

Script:

#!/bin/bash
# Check the type definitions being imported
cat src/types/crew-card.ts

# Also check for any other components using CrewCard
rg "from.*crew-card'" -g '*.tsx' -g '*.ts'

Length of output: 1406

Script:

#!/bin/bash
# Check the content of crew-card.ts from the correct location
fd -e ts -e tsx crew-card --exec cat {}

# Also check the pages using these types
cat src/app/\(crew\)/page.tsx
cat src/app/\(crew\)/my-crew/page.tsx

Length of output: 20437

src/mock/crew-data.ts (2)

1-24: 새로운 인터페이스 정의로 타입 안정성을 향상시켰습니다.

CrewMember, CrewDataItem, CrewData 인터페이스를 추가하여 데이터 구조의 명확성을 높였습니다.

Line range hint 26-471: 데이터 항목들이 새로운 인터페이스 구조에 맞게 잘 업데이트되었습니다.

모든 데이터 항목이 새로 정의된 인터페이스를 따르고 있으며, 타입 일관성이 유지되고 있습니다.

coderabbitai · 2024-11-11T05:05:31Z

src/types/writable-gathering-card.d.ts

 export type ParticipantType = {
  id: number;
-  profileImageUrl: string;
+  profileImageUrl?: string;


🛠️ Refactor suggestion

UI에서 undefined 처리 로직 추가를 권장드립니다.

profileImageUrl이 이제 선택적 필드가 되었으므로, 이 타입을 사용하는 UI 컴포넌트에서 이미지가 없는 경우에 대한 처리가 필요합니다.

다음과 같은 처리를 권장드립니다:

// 프로필 이미지 컴포넌트 예시 const ProfileImage = ({ participant }: { participant: ParticipantType }) => { const imageUrl = participant.profileImageUrl ?? '/default-profile.png'; return <img src={imageUrl} alt={`${participant.nickname}의 프로필`} />; };

coderabbitai · 2024-11-11T05:05:31Z

src/types/gathering-data.d.ts

  totalCount: number;
  imageUrl: string;
-  isLiked: boolean;
+  liked: boolean;


💡 Codebase verification

프로퍼티 이름 변경에 따른 코드베이스 불일치 발견

타입 정의 파일에서 변경된 프로퍼티 이름(liked, gatheringCaptain, participant)과 실제 컴포넌트 구현에서 사용 중인 이름(isLiked)이 일치하지 않습니다. 다음 파일들의 수정이 필요합니다:

src/components/common/gathering-card/presenter.tsx

src/components/common/gathering-card/container.tsx

src/components/common/input/button/like-btn.tsx

src/components/common/input/button/like-btn.stories.tsx

타입 정의와 구현 코드 간의 일관성을 유지하기 위해 모든 isLiked 사용을 liked로 변경해야 합니다.

🔗 Analysis chain

백엔드 API 응답과 타입 일치 여부 확인 필요

불리언 프로퍼티 이름이 더 간결하게 변경되었습니다. 하지만 이러한 변경사항이 백엔드 API 응답과 일치하는지 확인이 필요합니다.

백엔드 API 응답과의 일치 여부를 확인하기 위해 다음 스크립트를 실행하세요:

Also applies to: 16-17

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash # API 응답 타입과 관련된 파일들을 검색 rg -t ts "interface.*Response.*{[\s\S]*?(liked|gatheringCaptain|participant)[\s\S]*?}"

Length of output: 268

Script:

#!/bin/bash # Search for API response interfaces and types rg -t ts "interface.*Response" -A 5 # Search for usage of these boolean properties in API calls rg -t ts "(liked|gatheringCaptain|participant).*:.*boolean" # Search for axios or fetch API calls related to gatherings rg -t ts "axios\.(get|post|put|delete).*gathering.*" -A 3

Length of output: 2248

Script:

#!/bin/bash # Search for API related files fd -e ts -e tsx api # Search for gathering API implementations rg -t ts "gathering.*\.(get|post|put|delete)" -A 5 # Check for any remaining usages of old property names rg -t ts "(isLiked|isGatherCaptain|isParticipant)"

Length of output: 2361

coderabbitai · 2024-11-11T05:05:31Z

src/app/(crew)/my-crew/page.tsx

+        {/* <CrewCardList
          inWhere="my-crew"
          data={data}
          ref={ref}
          isFetchingNextPage={isFetchingNextPage}
-        />
+        /> */}


⚠️ Potential issue

주석 처리된 코드의 향후 계획 명시 필요

CrewCardList 컴포넌트가 주석 처리되어 있어 현재 페이지에서 크루 목록이 표시되지 않습니다. 이는 사용자 경험에 중대한 영향을 미칠 수 있습니다.

다음 사항들을 확인해주세요:

임시 UI나 대체 컴포넌트 구현 계획

새로운 데이터 구조에 맞는 컴포넌트 업데이트 일정

사용자에게 보여줄 로딩 상태나 임시 메시지

coderabbitai · 2024-11-11T05:05:31Z

src/components/common/gathering-card/scheduled-gathering-card/scheduled-gathering.stories.tsx

      imageUrl:
        'https://images.unsplash.com/photo-1601758260892-a62c486ace97?q=80&w=1470&auto=format&fit=crop&ixlib=rb-4.0.3&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D',
-      isLiked: true,
+      liked: true,


💡 Codebase verification

like-btn 컴포넌트에서 isLiked 속성이 아직 변경되지 않았습니다.

like-btn.stories.tsx 파일에서 아직 isLiked 속성이 liked로 변경되지 않았습니다. 다른 모든 컴포넌트는 이미 liked 속성을 사용하고 있어 일관성이 필요합니다.

src/components/common/input/button/like-btn.stories.tsx에서 다음 속성들을 변경해야 합니다:

isLiked 컨트롤 속성을 liked로 변경

기본 상태와 찜한 상태의 isLiked 속성을 liked로 변경

🔗 Analysis chain

속성 이름 변경이 올바르게 적용되었습니다.

백엔드 타입과의 일관성을 위해 isLiked에서 liked로의 속성 이름 변경이 적절하게 이루어졌습니다.

다른 컴포넌트에서도 동일한 변경이 적용되었는지 확인하겠습니다:

Also applies to: 54-54

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash # Description: 모든 스토리 파일에서 isLiked 속성이 liked로 변경되었는지 확인 # Test 1: isLiked가 남아있는지 확인 echo "=== 남아있는 isLiked 속성 확인 ===" rg "isLiked" -g "*.stories.tsx" # Test 2: liked로 변경된 부분 확인 echo -e "\n=== 변경된 liked 속성 확인 ===" rg "liked:" -g "*.stories.tsx"

Length of output: 1675

coderabbitai · 2024-11-11T05:05:31Z

src/app/(crew)/crew/detail/[id]/page.tsx

          <article>
-            <DetailCrewCard {...crewDetail} />
+            {/* //TODO: 추후 confirmed부분 수정 */}
+            <DetailCrewCard isConfirmed={false} {...crewDetail} />


💡 Codebase verification

⚠️ Potential issue

Let me analyze the results from the shell scripts to verify the concern about the hardcoded isConfirmed value.

The results show:

isConfirmed is defined as a required boolean prop in DetailCrewCardProps interface

Mock data in mock.json and crew-data.ts shows both true and false values being used

The component is used in stories with both true and false values

In crew-card-list.tsx, isConfirmed is dynamically passed based on conditions

The file in question ([id]/page.tsx) hardcodes it to false

I can now generate the final response:

crewDetail 데이터에서 isConfirmed 값을 사용해야 합니다

현재 하드코딩된 false 값 대신 crewDetail에서 제공되는 실제 isConfirmed 값을 사용해야 합니다. 코드베이스 분석 결과:

DetailCrewCard는 실제 확인 상태를 표시하는 컴포넌트입니다

다른 컴포넌트들은 동적으로 isConfirmed 값을 전달하고 있습니다

백엔드 API 응답(mock.json)도 이 필드를 포함하고 있습니다

수정 제안:

<DetailCrewCard {...crewDetail} />

🔗 Analysis chain

하드코딩된 isConfirmed 값의 검증이 필요합니다.

isConfirmed가 false로 하드코딩되어 있습니다. 이는 임시 해결책으로 보이며, 다음 사항들을 확인해주시기 바랍니다:

실제 확인 상태를 반영하는 동적 값으로 대체되어야 하는지

백엔드 API의 응답 타입과 일치하는지

다른 컴포넌트에서의 사용 사례와 일관성이 있는지

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash # Description: isConfirmed 프로퍼티의 사용 패턴을 검증합니다. # DetailCrewCard 컴포넌트에서 isConfirmed 프로퍼티의 사용을 확인 echo "DetailCrewCard 컴포넌트에서 isConfirmed 프로퍼티 정의 확인:" ast-grep --pattern 'interface DetailCrewCardProps { $$$ isConfirmed$_ $$$ }' # isConfirmed 프로퍼티가 다른 곳에서도 사용되는지 확인 echo "\nisConfirmed 프로퍼티의 다른 사용 사례 확인:" rg "isConfirmed" -A 2

Length of output: 5904

coderabbitai · 2024-11-11T05:05:32Z

src/components/common/gathering-card/scheduled-gathering-card/presenter.tsx

    totalCount: number;
    imageUrl: string;
-    isLiked: boolean;
+    liked: boolean;


💡 Codebase verification

liked 속성으로의 변경이 타입 일관성을 개선합니다

GatheringType과 GatheringCardProps 인터페이스에서 이미 liked: boolean 타입을 사용하고 있어, 이번 변경은 타입 시스템의 일관성을 높이는 올바른 수정입니다. 다만 LikeButton 컴포넌트의 props도 함께 수정이 필요할 수 있습니다.

src/components/common/input/button/like-btn.tsx의 LikeButtonProps 인터페이스도 isLiked를 liked로 변경하는 것을 고려해보세요.

🔗 Analysis chain

백엔드 타입과 일치하는지 확인이 필요합니다.

isLiked에서 liked로의 변경이 백엔드 API 응답 타입과 일치하는지 확인해주세요.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash # API 응답 타입에서 'liked' 필드 사용을 확인 rg -g '*.ts' -g '*.tsx' "type.*Response.*{[^}]*liked:"

Length of output: 68

Script:

#!/bin/bash # Search for interfaces or types containing 'liked' or 'isLiked' property ast-grep --pattern 'interface $_ { $$$ liked: $_ $$$ }' ast-grep --pattern 'interface $_ { $$$ isLiked: $_ $$$ }' # Search for API response types specifically rg -g '*.ts' -g '*.tsx' "type.*Response.*\{" -A 10

Length of output: 3709

coderabbitai · 2024-11-11T05:05:32Z

src/types/crew-card.d.ts

+  currentCount: number;
+  totalCount: number;
+  imageUrl: string;
+  totalGathering: number;


🛠️ Refactor suggestion

'totalGathering'을 'totalGatheringCount'로 변경하여 일관성 유지 제안합니다.

다른 인터페이스에서 총 모임 수를 나타내는 필드가 totalGatheringCount로 명명되어 있습니다. 일관된 명명은 코드의 가독성을 향상시킵니다.

변경 사항:

- totalGathering: number; + totalGatheringCount: number;

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

totalGathering: number;

totalGatheringCount: number;

coderabbitai · 2024-11-11T05:05:32Z

src/types/crew-card.d.ts

+  totalCount: number;
+  imageUrl: string;
  isConfirmed: boolean;
-  gatheringCount: number;


🛠️ Refactor suggestion

일관성을 위해 'isConfirmed'를 'confirmed'로 변경 제안합니다.

다른 인터페이스인 CrewDetail에서는 동일한 필드가 confirmed로 정의되어 있습니다. 필드 이름을 일관되게 유지하면 코드의 가독성과 유지보수성이 향상됩니다.

다음과 같이 수정할 수 있습니다:

- isConfirmed: boolean; + confirmed: boolean;

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

isConfirmed: boolean;

confirmed: boolean;

coderabbitai · 2024-11-11T05:05:32Z

src/types/crew-card.d.ts

+  mainLocation: string;
+  subLocation: string;
+  currentCount: number;
+  totalCount: number;


🛠️ Refactor suggestion

'currentCount'를 'participantCount'로 변경하여 일관성 유지 제안합니다.

MainCrewList 및 CrewDetail 인터페이스에서는 참여자 수를 나타내는 필드가 participantCount로 명명되어 있습니다. MyCrewList에서도 동일한 명명을 사용하면 혼동을 줄이고 유지보수성을 높일 수 있습니다.

변경 사항:

- currentCount: number; + participantCount: number;

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

currentCount: number;

participantCount: number;

coderabbitai · 2024-11-11T05:05:32Z

src/components/common/crew-list/crew-card-list.tsx

+              id={inform.id}
+              title={inform.title}
+              mainLocation={inform.mainLocation}
+              subLocation={inform.subLocation}
+              imageUrl={inform.imageUrl}
+              totalCount={inform.totalCount}
+              participantCount={
+                inWhere === 'my-crew'
+                  ? (inform as MyCrewList).currentCount
+                  : (inform as MainCrewList).participantCount
+              }
+              totalGatheringCount={
+                inWhere === 'my-crew'
+                  ? (inform as MyCrewList).totalGathering
+                  : (inform as MainCrewList).totalGatheringCount
+              }
+              crewMembers={inWhere === 'my-crew' ? (inform as MyCrewList).crewMembers : undefined}
+              isConfirmed={inWhere !== 'my-crew' ? (inform as MainCrewList).isConfirmed : undefined}


🛠️ Refactor suggestion

CrewCard 컴포넌트의 props 전달 방식 개선

inWhere 조건에 따라 여러 곳에서 타입 단언과 조건부 로직이 사용되고 있습니다. 이를 개선하기 위해 공통 인터페이스를 정의하거나, inform 객체를 미리 가공하여 타입 단언을 최소화하면 코드의 복잡성을 줄일 수 있습니다.

github-actions · 2024-11-11T05:11:10Z

🚀storybook: https://67206cc6ff9d7a05a3528ff8-ehycjudxjb.chromatic.com/

minkyung5x5

수고많으셨습니다!!!

github-actions · 2024-11-11T05:24:57Z

🚀storybook: https://67206cc6ff9d7a05a3528ff8-aolnhgzmhd.chromatic.com/

yulrang

번거로운 작업이었을텐데 수고많으셨습니다~!

coderabbitai

Actionable comments posted: 0

🧹 Outside diff range and nitpick comments (5)

src/app/_components/category/internal-category/index.tsx (2)
Line range hint 23-33: 접근성 개선이 필요합니다.

현재 eslint-disable 주석으로 접근성 규칙을 비활성화하고 있습니다. 더 나은 접근성을 위해 다음과 같은 개선을 제안드립니다:
-    // eslint-disable-next-line jsx-a11y/no-noninteractive-element-interactions
     <ul
+      role="list"
+      aria-label="카테고리 목록"
       ref={sliderRef}
       onMouseDown={handleMouseDown}
       onMouseUp={handleMouseUp}
       onMouseMove={handleMouseMove}
       onMouseLeave={handleMouseLeave}
       className="scrollbar-hide flex snap-x flex-nowrap gap-2 overflow-scroll scroll-smooth md:gap-3.5"
     >
Line range hint 34-42: className 로직의 가독성 개선이 필요합니다.

조건부 className 문자열이 너무 길고 복잡합니다. 가독성과 유지보수성을 높이기 위해 다음과 같은 리팩토링을 제안드립니다:
-            className={`${pathname?.includes(item.value ?? value) && 'bg-gray-900 text-white'} h-10 min-w-28 items-center justify-center text-nowrap rounded-xl bg-gray-100 px-5 py-2 text-center text-sm font-bold text-gray-400 transition-colors hover:bg-gray-900 hover:text-white md:h-11 md:text-lg`}
+            className={clsx(
+              'h-10 min-w-28 items-center justify-center text-nowrap rounded-xl',
+              'px-5 py-2 text-center text-sm font-bold transition-colors',
+              'md:h-11 md:text-lg',
+              pathname?.includes(item.value ?? value)
+                ? 'bg-gray-900 text-white'
+                : 'bg-gray-100 text-gray-400 hover:bg-gray-900 hover:text-white'
+            )}
clsx나 classnames 라이브러리를 사용하면 조건부 클래스를 더 깔끔하게 관리할 수 있습니다.
src/components/common/review-list/review-card-list.stories.tsx (1)

Line range hint 27-38: 주석 처리된 코드 정리가 필요합니다.

주석 처리된 RenderCrewReviewCardList 함수와 관련 스토리가 더 이상 필요하지 않다면 완전히 제거하는 것이 좋습니다. 코드의 가독성과 유지보수성을 높일 수 있습니다.

만약 이 코드가 나중에 필요할 수 있다면, 다음 중 하나의 방법을 고려해보세요:

Git 히스토리에 남기고 코드는 제거

TODO 주석과 함께 임시 보관 이유를 명시

Also applies to: 66-70
src/app/(crew)/mypage/page.tsx (2)
Line range hint 51-54: TODO 주석 처리가 필요합니다.

renderTabContent 함수의 TODO 주석을 해결해야 합니다. 컴포넌트로 교체하는 작업이 필요합니다.

컴포넌트 구현에 도움이 필요하시다면 제안해 드리겠습니다. GitHub 이슈를 생성해드릴까요?

목업 데이터 및 API 사용에 대한 개선이 필요합니다.

현재 코드베이스에서 다음과 같은 사항들이 확인되었습니다:

src/app/(crew)/mypage/page.tsx에서 하드코딩된 프로필 목업 데이터를 사용 중

mock-api 디렉토리에서 목업 API 구현이 있으며, 실제 프로덕션 API로의 전환 로직이 미비

API_BASE_URL이 환경 변수로 설정되어 있으나, 목업 API와 실제 API 전환을 위한 명확한 구조가 없음

개선 필요 사항:

하드코딩된 프로필 데이터를 실제 API 호출로 대체

목업 API를 개발 환경에서만 사용하도록 환경 분기 처리

프로덕션 API 엔드포인트 구현 및 연동

🔗 Analysis chain

Line range hint 15-19: 목업 데이터 사용에 대한 검토가 필요합니다.

현재 하드코딩된 목업 데이터를 사용하고 있습니다. 프로덕션 환경에서는 실제 데이터를 사용하도록 수정이 필요합니다.

다음 스크립트로 목업 데이터 사용 현황을 확인해보겠습니다:

Let me gather more information about mock data usage in the codebase.
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:
#!/bin/bash
# Description: 목업 데이터 사용 현황 확인

# mockData 변수 선언 검색
rg "mockData.*=.*{" -g "*.tsx" -g "*.ts"

# mock-api 디렉토리 내 파일 검색
fd -e ts -e tsx . | grep -i "mock"
Length of output: 2888

Script:
#!/bin/bash
# Check for mock data and mock API usage

# Search for mock data declarations
rg "mockData" -g "*.ts" -g "*.tsx" -A 5

# Search for mock API related files and imports
rg "mock-api" -g "*.ts" -g "*.tsx"

# Check if there are any environment-based API switching logic
rg "process\.env" -g "*.ts" -g "*.tsx" -A 2
Length of output: 3873

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 5c55f46 and 46d1b5d.

📒 Files selected for processing (7)

src/app/(crew)/my-crew/page.tsx (3 hunks)
src/app/(crew)/mypage/page.tsx (1 hunks)
src/app/(crew)/page.tsx (2 hunks)
src/app/_components/category/internal-category/index.tsx (1 hunks)
src/components/common/crew-list/crew-card-list.stories.tsx (2 hunks)
src/components/common/review-list/review-card-list.stories.tsx (1 hunks)
src/components/common/writable-gathering-card/writable-gathering-card-list.stories.tsx (1 hunks)

✅ Files skipped from review due to trivial changes (1)

src/components/common/writable-gathering-card/writable-gathering-card-list.stories.tsx

🚧 Files skipped from review as they are similar to previous changes (3)

src/app/(crew)/my-crew/page.tsx
src/app/(crew)/page.tsx
src/components/common/crew-list/crew-card-list.stories.tsx

🔇 Additional comments (4)

src/app/_components/category/internal-category/index.tsx (1)

4-4: import 경로의 일관성 확인이 필요합니다.

import 경로가 kebab-case 형식으로 변경되었습니다. 이는 Next.js 프로젝트의 일반적인 네이밍 컨벤션을 따르는 좋은 변경사항입니다.

다른 훅들의 네이밍 컨벤션도 일관성 있게 변경되었는지 확인하겠습니다:

✅ Verification successful

훅 파일들의 네이밍 컨벤션이 일관성 있게 적용되어 있습니다.

src/hooks 디렉토리의 파일들을 확인한 결과, use- 접두사가 있는 훅들은 모두 kebab-case 형식을 따르고 있습니다:

use-infinite-scroll.ts
use-slider.ts

따라서 useSlider에서 use-slider로의 변경은 프로젝트의 네이밍 컨벤션과 일치합니다.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: 훅 파일들의 네이밍 패턴 확인
# Expected: 모든 훅 파일들이 kebab-case를 사용하는지 확인

# src/hooks 디렉토리의 모든 파일 검색
fd . "src/hooks" --type f

Length of output: 98

src/components/common/review-list/review-card-list.stories.tsx (1)

2-2: import 경로 변경이 적절해 보입니다.

kebab-case로의 변경이 일관성 있게 이루어진 것으로 보입니다.

다른 파일들에서도 동일한 변경이 이루어졌는지 확인하겠습니다:

✅ Verification successful

import 경로가 모든 파일에서 일관되게 적용되었습니다.

검증 결과, useInfiniteScroll 훅의 import 경로가 모든 파일에서 kebab-case 형식(@/src/hooks/use-infinite-scroll)으로 통일되어 있으며, 이전 형식(@/src/hooks/useInfiniteScroll)의 사용이 발견되지 않았습니다.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: useInfiniteScroll 훅의 import 경로 일관성 확인

# 이전 형식의 import 경로가 남아있는지 확인
rg "from ['|\"]@/src/hooks/useInfiniteScroll['|\"]"

# 새로운 형식의 import 경로 사용 확인
rg "from ['|\"]@/src/hooks/use-infinite-scroll['|\"]"

Length of output: 827

src/app/(crew)/mypage/page.tsx (2)

5-5: 임포트 경로 변경이 적절합니다.

파일 네이밍 컨벤션을 kebab-case로 통일하여 일관성을 높였습니다.

Line range hint 31-41: 무한 스크롤 구현의 타입 안정성 검토가 필요합니다.

useInfiniteScroll 훅에서 사용되는 ReviewInformResponse와 WritableGatheringCardInformResponse 타입이 백엔드 타입과 일치하는지 확인이 필요합니다.

다음 스크립트로 타입 정의를 확인해보겠습니다:

#!/bin/bash
# Description: 관련 타입 정의 검색

# 타입 정의 파일 검색
rg "type (ReviewInformResponse|WritableGatheringCardInformResponse)" -g "*.ts" -g "*.d.ts"

# 해당 타입들의 사용처 검색
rg "(ReviewInformResponse|WritableGatheringCardInformResponse)" -g "*.tsx" -g "*.ts"

Also applies to: 42-50

Hotfix/95/fix type

HaeJungg added 9 commits November 11, 2024 10:32

🐛 fix: 백앤드 데이터라 따라서 타입, 값 변경

19fb83d

🐛 fix: 백앤드 데이터라 따라서 크루부분 타입, 값 변경

90cf98b

🎨 design: prettier changed

826a942

📝 docs: 주석추가

ebc9f13

🐛 fix: 빌드 에러 수정

c502374

♻️ refactor: 사용하지 않는 파일 삭제

647379c

🐛 fix: 데이터 변경될 부분 주석처리

b0530fc

🐛 fix: 백앤드 데이터라 따라서 크루부분 타입, 값 변경

ad88aa6

Merge branch 'develop' into Hotfix/95/FixType

5c55f46

HaeJungg self-assigned this Nov 11, 2024

HaeJungg linked an issue Nov 11, 2024 that may be closed by this pull request

전체적으로 타입 수정 #95

Closed

coderabbitai bot reviewed Nov 11, 2024

View reviewed changes

minkyung5x5 approved these changes Nov 11, 2024

View reviewed changes

HaeJungg added 2 commits November 11, 2024 14:21

🔧 fix: 파일 이름 컨벤션에 맞추기

167ab28

🎨 design: prettier changed

46d1b5d

yulrang approved these changes Nov 11, 2024

View reviewed changes

coderabbitai bot reviewed Nov 11, 2024

View reviewed changes

HaeJungg merged commit 5bb737f into develop Nov 11, 2024

HaeJungg added a commit that referenced this pull request Nov 13, 2024

Merge pull request #102 from CodeitFESI4-Team1/Hotfix/95/FixType

724496b

Hotfix/95/fix type

Hotfix/95/fix type #102

Hotfix/95/fix type #102

Uh oh!

Conversation

HaeJungg commented Nov 11, 2024 • edited by coderabbitai bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔖 Issue Ticket

✍️ Description

✅ Checklist

PR

Test

Summary by CodeRabbit

Uh oh!

coderabbitai bot commented Nov 11, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

Possibly related PRs

Suggested labels

Suggested reviewers

Chat

CodeRabbit Commands (Invoked using PR comments)

Other keywords and placeholders

CodeRabbit Configuration File (.coderabbit.yaml)

Documentation and Community

Uh oh!

github-actions bot commented Nov 11, 2024

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Nov 11, 2024

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Nov 11, 2024

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Nov 11, 2024

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Nov 11, 2024

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Nov 11, 2024

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Nov 11, 2024

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Nov 11, 2024

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Nov 11, 2024

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Nov 11, 2024

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Nov 11, 2024

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Nov 11, 2024

Uh oh!

minkyung5x5 left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Nov 11, 2024

Uh oh!

yulrang left a comment

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

HaeJungg commented Nov 11, 2024 •

edited by coderabbitai bot

Loading

coderabbitai bot commented Nov 11, 2024 •

edited

Loading

CodeRabbit Configuration File (`.coderabbit.yaml`)