[공통개발] [Next.js] [React] Naming Convention (네이밍 컨벤션), 프로젝트 구조, Code-Map (코드 한글 변환, 프론트 코드 관리)

 

📝──────────────── React Naming ────────────────

• custom hook file
  • kebab-case
  • 예) use-single-upload
• custom hook
  • use + PascalCase
  • 예) useSingleUpload
• 변수명
  • Camel Case
  • 예) fileFormData
• 페이지 컴포넌트
  • PascalCase + Page
  • UploadPage
• 디렉토리
  • kebab-case
  • item-category
• 파일명
  • kebab-case
  • global-error.tsx
• Redux Slice
  • 필드명은 스네이크 기법 → ad_item

 

나만의 주석 예시

/** ──── 상태관리 함수 ────**/

/** ──── Query & Mutation ────**/

/** ──── 상태관리 ────**/

/** ──── 이미 등록된 키워드인지 체크 ──── **/ (필요한 경우)

/** ──── TSX ────**/

{/*──── 선택 키워드 ────*/}

등...

 

Code-Map

export enum Code {
  /** ─── 상태 ─── **/
  WEAK = 'WEAK',     // '약함',
  NORMAL = 'NORMAL', // '보통', 
  STRONG = 'STRONG', // '강함,
}

type CodeMap = {
  [key in Code]: string;
};
export const CODE_MAP: CodeMap = {
  [Code.WEAK]: '약함',
  [Code.NORMAL]: '보통',
  [Code.STRONG]: '강함',
}

백엔드에서 코드로 내려온 경우 한글로 변환시키는 Mapping을 만들어두고 한 곳에서 관리하면 좋다

 

 

📝──────────────── Next.js Project Structure ────────────────

프로젝트 구조 (Next + 개인화) [redux + graphql]

src
├ components
│  ├ common
│     └ button.tsx
│  └ dashboard
│       └ pie-chart.tsx
├ config
├ constant
│  └ date-time-constant.ts
├ enums
│  └ code-map.enum.ts
├ assets
│  └ dog.png
├ gql
│  └ dashboard
│       ├ mutations.graphql
│       └ query.graphql
├ hooks
│  └ use-intersection-observer.ts
├ libs
│  └ utils.ts
└ redux
     ├ slices
     ├    └ modal-slice.ts
     ├ reducer.ts
     └ store.ts

 

📝──────────────── React.js Project Structure ────────────────

 

React 프로젝트 구조 (개인화) [redux 사용]

src
├ components
│  ├ common
│  │    └ button.tsx
│  └ dashboard
│       └ pie-chart.tsx
├ config
├ constant
│  └ date-time-constant.ts
├ enums
│  └ code-map.enum.ts
├ assets
│  └ dashboard
│       └ dog.png
├ config
├ services
│  └ dashboard
├ styles
│  └ dashboard
│       └ table.css
├ hooks
│  └ use-intersection-observer.ts
├ utils
│  └ utils.ts
└ redux
     ├ slices
     ├    └ modal-slice.ts
     ├ reducer.ts
     └ store.ts

• components
  • 재사용 가능한 컴포넌트들이 위치하는 폴더로 컴포넌트는 매우 많아질 수 있기 때문에 이 폴더 내부에서 하위폴더로 추가로 분류합니다
• assets
  
  • 컴포넌트 내부에서 사용하는 이미지 파일인 경우 이 assets 폴더에 위치시킵니다
• hooks
  
  • 커스텀훅이 위치하는 폴더입니다
• pages
  
  • 라우팅을 적용할 때 페이지 컴포넌트를 이 폴더에 위치시킵니다
• enums
  • enum 관련 파일이 들어갑니다
• constants
  • 공통적으로 사용되는 상수들을 정의한 파일들이 위치하는 폴더입니다
• config
  
  • config 파일이 따로 있는 경우 둡니다
• styles
  • css 파일이 포함되는 폴더입니다
• service
  • 외부 API와 상호작용하는 모든 코드들을 넣으며 auth와 같이 인증과 관련된 파일을 포함합니다
• utils
  
  • 정규표현식 패턴이나 공통함수 등 공통으로 사용하는 유틸 파일들이 위치하는 폴더
• redux
  
  • 리덕스 폴더가 들어갑니다

 

 

프로젝트 구조의 정답은 없다 React의 경우 feature으로 분리하는 방식을 많이 이야기한다 이걸 사용하면 ToDo 기능, 인증 등으로 기능별로 분리할 수 있다 feature/ToDo안에 ToDo관련 components, ToDo.tsx, css 등 관련된 걸 다 넣는다 이럴 경우 기능별로 딱 깔끔하게 되겠지만 양이 엄청 많아질 거고 A라는 페이지에서 쓰는 ToDo랑 B라는 페이지에서 쓰는 ToDo가 살짝 다를 수도 있다 특징별로 분리한 건 어떤 기능이 있는지 확인하고 기능별로 분리가 철저해 보이지만 실제 프로젝트를 하면 재활용성을 완벽하게 하는 경우가 그렇게 많지 않다

 

그럴바에 그냥 DDD구조처럼 중복되더라도 (Auth같이 무조건 공통인 경우는 따로 분리 필요) 살짝 달라서 안에서 분기태우고 이럴바에야 그냥 또 다른 이름으로 제대로 만드는게 좋아보인다

또한 업무도 페이지의 어떤 영역을 맡게 될테고 백엔드도 DDD구조로 가면 프론트에서도 찾기 쉽게 DDD로 가져가는게 프로젝트 이해와 해당 페이지를 찾는게 더 쉬워보인다 그래서 개인적으로는 DDD의 구조를 가져가는게 좋아보인다 

→ 물론 프론트랑 백엔드랑 확실히 구분되어있어서 프론트는 백엔드 프로젝트를 볼 일이 없을 경우는 제

 

물론 회사 프로젝트에서 이미 진행되고 있는 구조가 있다면 그렇게 따라가는 게 맞다

만약 이런 룰을 명확하게 하고 싶다면 프레임워크를 이용하면 된다 (Next.js)

 

 

 

 

🔗 참고 및 출처

https://velog.io/@cjkangme/%EB%A6%AC%EC%95%A1%ED%8A%B8%EC%9D%98-%ED%8F%B4%EB%8D%94-%EA%B5%AC%EC%A1%B0

https://velog.io/@sisofiy626/React-%EB%A6%AC%EC%95%A1%ED%8A%B8%EC%9D%98-%ED%8F%B4%EB%8D%94-%EA%B5%AC%EC%A1%B0