MILE 마일

☺️ 서비스 이름 및 소개

마일은 오직 글모임을 위한 글쓰기 공간을 제공합니다.
MILE은 make it look easy의 줄임말로, 글쓰기를 더 쉽고, 편안하게 만드는 것을 목표로 하는 서비스라는 의미를 담고 있습니다.

---

👀 View 소개

🌱 Main View

🌱 Post View

🌱 Post Editor View

🌱 Post Detail View

👩🏻‍💻🧑🏻‍💻 MILE Web Developers

팀원	이재훈	윤서진	문다현	남다은
팀원 소개
역할	WEB FRONTEND	WEB FRONTEND	WEB FRONTEND	WEB FRONTEND

---

🛠 기술스택

역할	종류
Library
Programming Language
Styling
Data Fetching
Formatting
Package Manager
Version Control

💡 주요 라이브러리

• "@emotion/react": "^11.11.3"
  
• "vite-plugin-svgr": "^4.2.0”
  
• quillJS
  
• @types/react-slick": "^0.23.13"

✍🏻 컨벤션

📏 컨벤션 노션 링크

✨ Git 컨벤션

1️⃣ Commit 컨벤션

Commit Type

type: subject 
type과 콜론 후 한칸 띄고 subject 

• Commit 메시지 종류 설명

제목	내용
init	브랜치 첫 커밋
feat	새로운 기능에 대한 커밋
fix	버그 수정에 대한 커밋
build	빌드 관련 파일 수정에 대한 커밋
chore	그 외 자잘한 수정에 대한 커밋
docs	문서 수정에 대한 커밋
style	코드 스타일 혹은 포맷 등에 관한 커밋
refactor	코드 리팩토링에 대한 커밋
etc	위에 해당하지 않는 모든 변경(가능한 x)
test	테스트 코드 추가, 삭제, 변경

2️⃣ Branch 전략

• Git-Flow 전략
• 브랜치 운영
  • main : 완전히 안전하다고 판단되었을 때, 즉 배포가 가능한 최종 merge하는 곳
  • develop : 배포하기 전 개발 중일 때 각자의 브랜치에서 merge하는 브랜치
  • feat/#issue/기능명: feature 브랜치. 새로운 기능 개발. 개발이 완료되면 develop 브랜치로 병합
  • fix/#issue/기능명 : feature브랜치 생성 후 버그가 생겼을 때 수정하는 브랜치

  main
    ㄴ develop
      ㄴ feat/#이슈번호/기능명(camelCase)

3️⃣ 코드리뷰 룰 - PN룰

- 뱅크샐러드에서 사용하고 있는 코드리뷰 룰인 PN룰을 사용해서 코드리뷰에서 필요한 커뮤니케이션 비용을 최소화하고자 했습니다.

✨ Project 컨벤션

1️⃣ 폴더 구조

• 사용되는 파일을 가까이 모아서 배치

|-- 📁 node_modules
|-- 📁 public
|-- 📁 src
    |-- 📁 assets
	  |   |-- 📁 svgs
	  |   |-- 📁 images
    |-- 📁 components
	  |   |-- 📁 commons (button , input 등 재사용의 가장 작은 단위
	  |   |-- 📁 icons(React Icon Components)
    |-- 📁 pages
    |	|   |-- 📁error
    |	|   |-- 📁login
    |	|   |-- 📁main
    |   |       |-- 📁apis
    |   |    	|-- 📁components
    |   |    	|-- 📁types
    |   |    	|-- 📁constants
    |   |    	|-- 📁styles
    |   |	|-- 📁types
    |   |    	|-- Main.tsx
    |   |   |-- 📁postDetail
    |   |       |-- 📁apis
    |   |    	|-- 📁components
    |   |    	|-- 📁constants
    |   |	|-- 📁hooks
    |   |    	|-- postDetail.tsx
    |   |   |-- 📁postEditor
    |   |       |-- 📁apis
    |   |    	|-- 📁components
    |   |    	|-- 📁constants
    |   |	|-- 📁hooks
    |   |    	|-- postEditor.tsx
    |   |   |-- 📁postPage
    |   |       |-- 📁apis
    |   |    	|-- 📁components
    |   |    	|-- 📁constants
    |   |	|-- 📁types
    |   |    	|-- postPage.tsx
    |   |   |-- 📁groupFeed
    |   |       |-- 📁apis
    |   |    	|-- 📁carousels
    |   |    	|-- 📁components
    |   |    	|-- 📁constants
    |   |	|-- 📁hooks
    |   |    	|-- groupFeed.tsx
    |   |  
    |   |   
    |   |
    |-- 📁 hooks (커스텀 훅을 담아두는 폴더)
    |-- 📁 styles ( GlobalStyles , theme.ts )
    |-- 📁 utils ( 재사용이 높은 함수모음 폴더 )
    |   |-- 📁 apis
    |   |-- 📁 mocks
    |-- 📁 types
    |-- Router.tsx (라우터 파일)
    |-- App.tsx
    |-- main.tsx
|-- .eslintrc.json
|-- .gitignore
|-- .prettierrc
|-- README.md
|-- package.json
|-- tsconfig.json
|-- yarn.lock
...

2️⃣ Coding Conventions

1. 컴포넌트

• rafce
• 의미없는 div 또는 컴포넌트 최상단은 fragment 사용하기
• children이 불필요할 땐 selfClosing 사용하기 <Component/>

구분	네이밍 규칙
리액트 컴포넌트 파일 명	PascalCase
그 외(컴포넌트 x) 파일 명 (ex. 하위 폴더, 페이지)	camelCase

2. 폴더명

• 소문자로 시작하기
• 뒤에 s 붙이기
• camelCase

3. 타입

• extends로 확장할 수 있을 땐 interface
• intersection union으로 합칠 수 있을 땐 type 키워드 사용
• PascalCase 사용
• 공통 타입아니면 컴포넌트 상단에 기입

4. 변수

• var 금지.
• const → let 순서로 위부터 선언.
• 변수를 조합하여 문자열 생성시 “+ “ 금지. → 리터럴 사용(백틱 ```)
• 상수는 영문 대문자 스네이크케이스 : API_KEY
• 변수명 : 의미 + 간결함. “알잘딱”
  • 예시 : 배열에 Arr 보다는 변수s = fruits, userlists 등등
• 만약 변수에 할당되는 값이 boolean인 경우에는 is를 접두사로 붙인다.
  • isActive 같이 is 키워드는 boolean에만 적용
• map 사용시 변동되는 리스트라면 key값을 고유하게 잘 설정해주기 index사용금지

5. 함수

• 함수명 : 어떤 일을 하는지 명확히 묘사. 동사+명사의 형식.

구분	의미
get	어떤 값을 얻는 함수
create	갖고 있는 변수를 활용, 새로운 값과 변수를 만듦
check	함수 안의 로직을 확인
handle	이벤트 핸들링 함수 - 이벤트 핸들링 함수가 많을때는 동작까지 포함
has~	boolean값 반환시
그 외	기능을 분명하게 드러내도록 네이밍

• 유틸함수는 반환값을 기준으로 이름 네이밍
  • boolean값 반환시 has—- ex) hasEmail = email이 존재하는지 여부를 반환하는 함수
• 중복함수는 utils 폴더에 모아서 재사용한다.
• 되도록 화살표 함수를 사용한다.

6. 메소드

• 배열 복사시 → 스프레드 연산자(…) 사용
  • const copys = […originals]
• for 보단, forEach/map을 사용
• 구조 분해 할당을 적극 이용

interface voteAllInfoPropType {
  date: number;
}

interface userDataPropsTypes {
	userName:string;
	userBirth:string;
}

export default function MonthVoting(props: voteAllInfoPropType){
  const { date } = props;
 ...
}

function checkIsUser({userName, userBirth}:userDataPropsTypes){

}

• 불필요한 반복문 지양 : filter, array.include() 등
  • 조건부로 데이터를 확인하거나 뽑아야하는 로직을 사용할 때에는 Map 이나 Object처럼 key값을 이용해서 원소를 찾는 자료형을 이용하는것을 고려해보거나,
  • 배열을 순회하지 않고 index로 바로 접근할 수 있는 방법이 없는지 고려.

7. Style

• 최대한 시맨틱 태그 잘 활용하기.

Emotion

• style 파일을 분리하지 않음 → s dot 네이밍 사용하지 않기 → DX 상승

• st 객체 사용하지 않기

• 선택자 사용하지 않기, className 사용하지 않기 → 최대한 다 스타일드 컴포넌트로

• 컴포넌트 네이밍

• 컴포넌트를 감싸는 컴포넌트 : Wrapper → Layout → Container → Box

• svg 파일 사용시 : svg네이밍은 Ic로 해준뒤, 스타일드 컴포넌트 네이밍에 Icon 붙여주기.

태그	의미
div	'컴포넌트명'Box
section	'컴포넌트명' Section
ul	함수 안의 로직을 확인
li	'컴포넌트명' Item
p	'컴포넌트명' Text
span	'컴포넌트명'Span

---