[김강우] sprint8

[hvrain]

요구사항

기본 요구사항

• Github에 PR(Pull Request)을 만들어서 미션을 제출합니다.
• 피그마 디자인에 맞게 페이지를 만들어 주세요.
• Typescript를 사용합니다

기본 체크리스트

• 스프린트 미션 1 ~ 7에 대해 typescript를 적용해주세요

멘토에게

• 스프린트 미션 6까지 typescript 적용했습니다. 미션 7은 아직 완성을 못해서 차근차근 올리겠습니다.

[Taero-Kim]

p3;
단일 제품에 대한 api의 결과이므로, 이에 맞게 타입명도 변경되면 좋을 것 같아요!
그냥 직관적으로는 Product , ProductDetails 과 같은 타입명이 좋아보이고,
api의 응답결과인 것을 명시적으로 표현하고 싶으시다면 ProductResponse 등도 괜찮은 것 같습니다.

개인적으로는 Product , ProductDetails 등이 가장 직관적인 것 같아요!

[Taero-Kim]

p4;
api 요청시 전달되는 QueryString은 �보통 옵셔널하게 전달할 수 있도록 설계되어 있을 것 같아요!
해당 인터페이스의 각 프로퍼티를 옵셔널하게 할 수 있도록 하면 좋을 것 같아요!

[Taero-Kim]

p4;
요부분도 URLSearchParams 등을 사용해서 쿼리스트링을 만들고 붙이면 어떨까 싶어요!

[Taero-Kim]

p4;
뒤에 붙는 limit와 cursor 같은 comment api 호출시 전달하는 옵션도 따로 interface로 정의해서 사용하면 더 깔끔할 것 같아요!

interface GetCommentsOptions {
  limit?: number;
  cursor?: number;
}

export const getComments = async (
  id: number,
  { limit, cursor = 0 }: GetCommentsOptions
): Promise<CommentsApi> => {...}

[Taero-Kim]

p4;
children을 직접 정의해도 되지만, React에서 제공하는 PropsWithChildren 유틸리티 타입을 사용해서 children prop을 자동으로 포함할 수 있습니다!

import { PropsWithChildren ... } from "react";

interface SubmitProps {
  isValid: boolean;
}

const Submit = ({ isValid, children }: PropsWithChildren<SubmitProps>) => {
  return (
    <button >{children}</button>
  );
};

[Taero-Kim]

p4;
요 부분도, PropsWithChildren 유틸리티 타입을 사용해도 좋을 것 같아요!

추가적으로 Reac.FC 타입을 사용하면 가독성이 더 좋아질 것 같아요!

const H1: React.FC<PropsWithChildren> = ({ children }) => {
  return <h1 className="h1__items">{children}</h1>;
};

[Taero-Kim]

p3;
매핑되는 요소들에 적절한 key를 부여하면 좋을 것 같아요!

[Taero-Kim]

p4;
INITIAL_VALUE가 ItemType이라는 것을 명시하면 더 좋을 것 같아요!
추가적으로 변수명이 조금더 구체화되면 좋을 것 같아요!

const INITIAL_ITEM_VALUE: ItemType = {
  imageFile: null,
  title: "",
  content: "",
  price: "",
  tag: "",
};

[Taero-Kim]

p3;
Sice -> Size 오타인듯 하네용

디바이스별 fetching size 옵션을 상수로 관리하는 건 어떨까요?
또한, getFetchingSiceByDevice 리턴하는 값도 단순 number가 아닌, 4,6,10으로 관리되도록 하면 아주 명확할 것 같아요!

const FETCHING_SIZE = {
  MOBILE: 4,
  TABLET: 6,
  DEFAULT: 10,
} as const;

type FetchingSize = typeof FETCHING_SIZE[keyof typeof FETCHING_SIZE];

function getFetchingSizeByDevice(isMobile: boolean, isTablet: boolean): FetchingSize {
  if (isMobile) return FETCHING_SIZE.MOBILE;
  if (isTablet) return FETCHING_SIZE.TABLET;
  return FETCHING_SIZE.DEFAULT;
}

[Taero-Kim]

breakPoints 에 따라서 미디어 쿼리를 간편하게 적용할 수 있도록 타입 정와 더불어 유틸리티를 잘 정의하셨네요!

[Taero-Kim]

안녕하세요, 강우님! 타입스크립트 정의된 부분들 위주로 코드를 살펴봤어요.
전반적으로 타입정의도 잘하시고 이해도도 좋으신 것 같아요!

코드를 보며 조금 개선하면 좋을 부분들에 대해서 간단한 리뷰들을 남겼습니다.
제가 남긴 리뷰에 대한 질문이나 기타 궁금하신 사항이 있으시면 언제든 편하게 말씀해주세요!

+) 리뷰를 남긴 코멘트 위의 p(1~5); 마크의 의미는 아래와 같습니다! 참고하면 좋을 것 같아요!

p1; 꼭 반영해주세요 (Request changes)
리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.

p2; 적극적으로 고려해주세요 (Request changes)
작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.

p3; 웬만하면 반영해 주세요 (Comment)
작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다.

p4; 반영해도 좋고 넘어가도 좋습니다 (Approve)
작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.

p5; 그냥 사소한 의견입니다 (Approve)
작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.