[강대원] sprint11#140
Hidden character warning
Conversation
Next 강대원 sprint9
… 불필요한 type, basePath prop 제거
There was a problem hiding this comment.
빠르게 프로타이필을 하기에는 확실히 tailwind가 좋은 면이 있지만, 이처럼 arbitrary value가 자주 사용되는 경우 안 좋은 패턴을 양산할 수 있으므로 적당한 시점에 컴포넌트나 custom class 등으로 정리를 해보시면 좋을 것 같습니다.
There was a problem hiding this comment.
productData가 마지막 리턴 구문에만 쓰이기 때문에
if return
if return
변수 할당
return
순으로 코드를 배치했을 수도 있겠다 싶은데요. 관점을 조금 전환해서
- 훅
- 변수 할당
- 리던(렌더)
순으로 섹션을 나눈다고 생각하면 return 꾸문 3개를 모아두는 게 가독성을 높이는 측면에서 더 좋은 선택일 수 있습니다.
There was a problem hiding this comment.
@pers0n4
확실히 코드를 생각하면 return 구문을 3개를 모아두는 게 가독성을 높일 수 있다는 것에 공감됩니다.
하지만 조건식으로 리턴을 하지 않는다면 product가 없다고 타입 에러가 발생하는데 어떤식으로 해결하면 좋을까요?
그렇다고 productData : ProductCreateRequest | null 타입으로 하면 타입이 번잡해지고, props를 전달할때도 props를 전달하는 컴포넌트의 전달받는 타입에서도 옵셔널 체이닝으로 처리하게됩니다.
There was a problem hiding this comment.
대원님이 제기하신 2가지 우려점에 대한 관점을 한번 바꿔볼까요?
- ProductCreateRequest | null는 타입이 번잡해진다
- ProductCreateRequest | null는 정말 번잡한 타입일까?
- 타입의 복잡성을 조금 높이는 대신 코드의 밀집도를 높이는 선택 vs 타입의 단순함을 보장하기 위해 코드의 밀집도를 낮추는 선택 중 어떤 것이 진짜 번잡해지는 걸까?
- props를 전달할 때도 옵셔널 체이닝으로 처리하게 된다
- 진짜 그런 문제가 있을까?
const { data: product, isLoading } = useQuery({
queryKey: ["product", productId],
queryFn: () => getProduct(productId),
});
const productData: ProductCreateRequest | null = product && {}
if (isLoading) return <LoadingSpinner />;
if (!productData) return <div>상품을 찾을 수 없습니다.</div>;
return (
<section className="max-w-container mx-auto box-border px-6 pb-40 pt-6">
<ProductForm
{ /* 위 라인에서 productData가 null인 조건을 배제했기 때문에 여기서는 항상 참임 */ }
defaultValues={productData}
productId={productId}
isEdit={true}
/>
</section>
);
app/(routes)/items/page.tsx
Outdated
|
|
||
| return ( | ||
| <article className="px-6 py-7"> | ||
| <section className="mx-auto flex max-w-[1200px] flex-col gap-10"> |
There was a problem hiding this comment.
1280px은 계속해서 등장하고 있군요. 아예 경계해야 한다고 말씀드렸던 패턴이 바로 지금 이 상황이긴 합니다.
두세 번 반복됐을 때 반복을 줄일 수 있는 수단을 마련해두면 다음부터는 그걸 사용하면 되지만, 관성 때문에 이렇게 쓰던대로 쓰다 보면 나중에는 점점 더 고치기 힘들어지게 되겠죠?
There was a problem hiding this comment.
@pers0n4
확인해보니 max-w-[1200px] 이렇게 사용한 페이지가 많았네요..항상 컬러와 폰트, 반응형에 따른 크기 설정만 tailwind custom class로 설정했는데 maxWidth로 해야겠다는 것을 덕분에 알게되었습니다!
max-w-container로 custom해서 적용했습니다!
고민했던 것: max-w-container이 나을지, max-w-1200 직관적으로 보이는 것이 좋을지에 대해 고민했었습니다.
저의 생각: 컴포넌트의 section 태그의 container처럼 활용하여 max-w-container로 하였습니다.
There was a problem hiding this comment.
utils는 일반적으로 '널리 쓰일 수 있는 함수'를 의미하는데, 이 프로젝트에서는 전부 상수를 정의하는 용도로 사용되고 있군요. 이 경우는 1차 디렉터리 자체를 constants로 분류해보면 어떨까요?
| staleTime: 5 * MINUTES, | ||
| gcTime: 30 * MINUTES, | ||
| refetchOnWindowFocus: false, | ||
| refetchInterval: 1000 * 60 * 10, | ||
| refetchInterval: 10 * MINUTES, |
There was a problem hiding this comment.
상수 대신 함수를 만들어서 사용하는 방식도 괜찮을 것 같아요.
| id: string; | ||
| }; | ||
|
|
||
| type DropdownStates = { [key: string]: boolean }; |
There was a problem hiding this comment.
Record 타입을 활용해보세요. 가독성이 더 향상될 겁니다.
| onEdit={() => { | ||
| // 댓글 수정 페이지로 이동 | ||
| router.push(`/comments/${comment.id}/edit`); | ||
| }} |
There was a problem hiding this comment.
액션만 고려하면 이벤트로 라우트를 처리할 수 있겠지만, 웹의 본질과 접근성을 고려하면 anchor와 href 속성을 통해 링크를 나타내는 것이 좋습니다.
2 participants
요구사항
기본
프론트엔드
주요 변경사항
스크린샷
멘토에게
백엔드를 NestJS로 처음부터 다시하려니 시간이 많이 걸려 프론트에 신경을 많이 쓰지 못했지만, SSR을 통해 성능이 좋아졌다는 점과 lighthouse 성능 측정을 하면서 색상대비로 인해 점수가 깎일 수 있다는점을 이번주에 알게되었습니다!
CSR vs SSR 차이가 두드러지는 것 확인
CSR
-> CSR보다 SSR이 SI(1.5s > 0.4s), LCP(2.5s > 2.1s) 가 좋게 나왔으나 TBT는 점수는 큰 차이가 없다는 것을 알게되었습니다.
SSR 후기
장점
단점
셀프 코드 리뷰를 통해 질문 이어가겠습니다.