<aside>
💡 コンベンション 関連
<aside>
💡 GTS(Google Typescript Style)
[TypeScript] 타입스크립트 스타일 가이드 요약 📋 (Ver. Google) / 1️⃣ - 식별자 (Identifiers)
</aside>
<aside>
💡 命名規則(参考用)
React / TypeScript の設計前に、改めて命名規則について把握する - Qiita
</aside>
</aside>
<aside>
💡 インポート規則
**//良い例
import A from './AFolder';
import B from '../BFolder';
import C from '@/src/components/Cfolder';
//悪い例
import A from '../../AFolder';
import B from './BFolder/';**
Component / API / Interface
Modules (변수 등)
Img, svg 파일
</aside>
<aside>
💡 テストコード
Next Js 12以上のバージョンから テスト環境を提供する Jest
が 基本的に含まれています
React-Testing-Library
の使用もおすすめです
Next.js + TypeScript 환경에서 Jest와 react-testing-library 셋팅하기
Jest 가이드
https://www.youtube.com/watch?v=g4MdUjxA-S4&list=PLZKTXPmaJk8L1xCg_1cRjL5huINlP2JKt
</aside>
<aside>
💡 役割分担
<aside>
💡 Github Flow
[설계] Git Branch 전략이란? & Git Branch 전략 알아보기 (Git Flow, GitHub Flow)
Branch 작명 규칙 // 공통사항 : 띄워쓰기는 - 로 구분할 것
ex) 클래스 내부의 실시간 스트리밍 개발→ feat/class-stream
</aside>
**components // 메인 폴더
- common
- Alert
- index.tsx
- styles.tsx
- pages
- ( main )
- Acomponent
- index.tsx
- styles.tsx
- auth
- Bcomponent
- index.tsx
- styles.tsx**
전역적으로 관리
하는 경우: 텍스트가 여러 페이지에서 공통으로 사용된다면, 이를 전역적으로 관리하는 것이 유리합니다. 예를 들어, '로그인', '로그아웃' 같은 공통 버튼 라벨이나, 공통적으로 사용되는 에러 메시지 등은 전역적으로 관리하는 것이 효율적일 수 있습니다. 이 경우에는 일반적으로 별도의 파일이나 폴더를 만들어서 텍스트를 관리합니다.
페이지별로 관리하는 경우: 특정 페이지에서만 사용되는 텍스트가 있다면, 해당 페이지에서만 관리하는 것이 더 효율적일 수 있습니다. 이렇게 하면 해당 페이지의 컴포넌트나 로직과 깊게 연관된 텍스트를 쉽게 찾을 수 있습니다.
이 두 가지 방식은 서로 배타적인 것이 아니며, 실제 프로젝트에서는 이 두 가지 방식을 적절히 혼합하여 사용하는 경우가 많습니다. 가장 중요한 것은 코드의 가독성과 유지보수성을 최대한 높이는 것입니다. 따라서, 프로젝트의 특성과 요구사항에 따라 가장 적절한 방식을 선택하는 것이 중요합니다.