Conversation
NextJS 디렉터리 구성을 FSD(Feature Sliced Design) 패턴을 따르도록 설정하였습니다.
Commit 시마다 ESLint Linting 및 Prettier Formatting을 자동으로 수행하도록 설정
@svgr/webpack과 ky를 디펜던시에 추가했습니다. - @svgr/webpack 패키지를 설치하여 svg 파일을 React 컴포넌트로 다룰 수 있도록 설정 - 데이터 fetch를 위해 ky 라이브러리를 디펜던시에 추가
- 공통 UI 컴포넌트(Header, Footer 등) 스타일 구성 - 프로젝트의 FSD 디렉터리 구성에 따라 tailwind.config.ts 파일 수정 - Commit 시마다 ESLint Linting 및 Prettier Formatting을 자동으로 수행하도록 설정 - husky v9 기준으로 shell script 재작성
공통적으로 사용하기 위해 shared에 ky wrapper(apiClient)를 작성하였습니다
There was a problem hiding this comment.
프로젝트 전체에 사용된 기술스펙이 많이 보이는것 같아요.
첫 멘토링시간에도 강조했듯이 사용하는게 중요한게아니라 각각의 스펙들이 어떤 이점을 가져올 수 있고, 또 내부적으로는 어떻게 동작하는지 이해하는게 중요합니다.
또한 Next는 현재 스프린트과제에 포함되지 않는 기술스펙으로 알고있어요. 하지만 사용하신다면, 또한 앱라우터 기준으로 구성해주신만큼 그에맞는 컴포넌트 구성방식이 필요합니다. 폴더구조나 서버컴포넌트, RSC의 사용방식, 비동기처리, 다이나믹에 관련된 내용들 포함해서 많은 내용들에 정리가 필요할 것 같아요. 이후에도 이스펙으로 계속 구성하신다면 그에맞는 리뷰로 다시 돌아오겠습니다!
| @@ -0,0 +1,7 @@ | |||
| { | |||
There was a problem hiding this comment.
eslint를 사용해주셧군요!
lint는 협업에서 중요한 요소중 하나가 될것입니다. 기본적인 컨벤션 이외에도 커스텀룰들을 가지고 팀의 코드를 관리하기 용이하죠.
기회가 되면 한번 소개해보겠습니다!
| @@ -0,0 +1,4 @@ | |||
| #!/usr/bin/env sh | |||
There was a problem hiding this comment.
husky도 사용해주셨군요?!
husky도 협업에서 필요한 요소를 포함합니다. 또한 CI/CD를 위해서도 사용하기도하고요 이것도 기회가 되면 실제 사례를 소개해볼게요!
| } | ||
| ], | ||
| "paths": { | ||
| "@/app": ["src/app"], |
There was a problem hiding this comment.
tsconfig로 path를 잘게 나누어주셨네요! 여기서
"@/app": ["src/app"],
"@/app/*": ["src/app/*"],
이렇게 두가지는 와일드카드패턴이기때문에 같은 경로를 확인해주고 있어서 중복인것 같아요.
"@/app/styles/*": ["src/app/styles/*"],
"@styles/*": ["./src/app/styles/*"],
여기도 같은 경로를 보고있습니다!
There was a problem hiding this comment.
패키지매니저를 pnpm으로 구성해주었네요!
패키지매니저는 크게 3가지가 존재하는데 가각 서로 장단점을 보유하고있습니다. 이것도 기회가되면 소개하고싶네요
| "dependencies": { | ||
| "3-sprint-mission-fe": "link:", | ||
| "ky": "^1.7.2", | ||
| "next": "^14.2.16", |
There was a problem hiding this comment.
next를 통해서 프로젝트를 구성해주셧네요.
next는 프레임워크로써 리액트의 수퍼셋으로 사용되고있습니다. 하지만 리액트보다 많은 복잡도와 기술들으 요구합니다.
프로젝트를 구성할땐 기술을 사용하는 명확한 이유가 있어야된다고 생각합니다. 단순히 경험해보고싶어서 라는 이유가 있을 수는 있지만 실제 면접에서도 이렇게 말하면... 좋지않은 대답이 될 수 있겠죠?
현우님이 이 프로젝트에서 next를 사용하고 싶은 이유를 찾아서 정리해주셔야 합니다. (ex. 커머스 서비스이기때문에 SSR또는 SEO의 이점을 가지고 가고싶다, next/image를 통해 이미지 최적화를 하고싶다 등.. 그리고 이어서 이게 어떻게 next통해서 가능한지가지)
이런점이 없다면 단순히 많은 기술을 사용하는것은 구현스펙에 맞지않는 오버엔지니어링이 될 수 있습니다.
| const productApi = { | ||
| async getProducts(params: ProductsParams) { | ||
| try { | ||
| const queryParams = new URLSearchParams(params as URLSearchParams); |
There was a problem hiding this comment.
일반객체 타입인 ProductsParams를 URLSearchParams로 캐스팅하는건 좋은방법이 아닐것 같습니다.
타입자체를 as로 단언하는것이 타입안정성을 깨는 첫번째 요소입니다.
axios를 사용하신다면 queryParams, queryString을 구성하는방법이 여러개 존재합니다. 그중 기본적으로 내장되어있는 paramsSerializer 를 활용할 수 있을것 같아요
| const response = await apiClient.get<ApiResponse<Product>>('products', { searchParams: queryParams }).json(); | ||
| return response; | ||
| } catch (error) { | ||
| console.error('Products 조회에 실패하였습니다.', error); |
There was a problem hiding this comment.
에러에서 로그만 남기고있습니다. 실제로 에러가발생했을때 대처방안이 필요할 수 있습니다.
또한 API에러는 서비스에 심각한 버그를 유발할 수 있으니 어떤방식으로든 사용자가 알 수 있도록 상위로 throw하거나 UI적인 요소로 노출할 수 있어야합니다. 또한 개발자가 확인할 수 있도록 로그 이외의방식으로도 에러를 컨트롤 할 수 있어야 합니다.
| </ul> | ||
| <ul className='flex items-center justify-between gap-6'> | ||
| <li className='signin'> | ||
| <a |
There was a problem hiding this comment.
next를 사용하는만큼 preload를 위해 <Link /> 사용하는것이 더 유리할수 있겠네요
| import { facebookLogo, instagramLogo, twitterLogo, youtubeLogo } from '@/shared/assets/icons'; | ||
|
|
||
| const Footer = () => { | ||
| return ( |
There was a problem hiding this comment.
컴포넌트가 전체적으로 하드코딩된 모습입니다.
적절한 단위로 나누고 컴포넌트를 구성할 수 있을것 같아요
There was a problem hiding this comment.
svg파일들을 src 하위에서 관리중인걸 볼 수 있는데요,
svg를 리액트 컴포넌트로써 동적으로 사용하려면 유효할 수 있지만 현재는 static요소로사용하고 있는것 같아요.
next에서는 이미지와 같은 static을 관리하는 방식이 존재합니다. 한번 보시면 좋을 것 같아요
요구사항
기본 요구사항
공통
중고마켓 페이지
심화 요구사항
공통
중고마켓 페이지
멘토에게