Skip to content

Mile-Writings/Mile-Client

This branch is 5 commits ahead of, 11 commits behind develop.

Folders and files

NameName
Last commit message
Last commit date

Latest commit

f3e5550 · Dec 13, 2024
Jan 7, 2024
Mar 23, 2024
Dec 13, 2024
Jan 4, 2024
Aug 16, 2024
Dec 2, 2024
Jan 1, 2024
Nov 11, 2024
Jan 1, 2024
Oct 16, 2024
Oct 11, 2024
Jan 7, 2024
Nov 11, 2024
May 7, 2024
Jan 1, 2024
Jan 17, 2024
Nov 5, 2024
Nov 11, 2024

Repository files navigation

MILE 마일

☺️ 서비스 이름 및 소개

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


👀 View 소개

🌱 Main View

onBoarding Carousel q a

🌱 Post View

스크린샷 2024-01-16 오후 11 55 29 스크린샷 2024-01-16 오후 11 03 12

🌱 Post Editor View

2024-01-19_2 43 03 스크린샷 2024-01-18 오전 2 52 32 스크린샷 2024-01-19 오후 5 53 11

🌱 Post Detail View

스크린샷 2024-01-16 오후 11 59 26 스크린샷 2024-01-16 오후 11 09 39

👩🏻‍💻🧑🏻‍💻 MILE Web Developers


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

WEB FRONTEND

WEB FRONTEND

WEB FRONTEND

WEB FRONTEND



🛠 기술스택

역할 종류
Library React VITE
Programming Language TypeScript
Styling Emotion
Data Fetching Axios ReactQuery
Formatting ESLint Prettier Stylelint
Package Manager Yarn
Version Control Git GitHub


💡 주요 라이브러리

  • "@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 금지.
  • constlet 순서로 위부터 선언.
  • 변수를 조합하여 문자열 생성시 “+ “ 금지. → 리터럴 사용(백틱 ```)
  • 상수는 영문 대문자 스네이크케이스 : 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 사용하지 않기 → 최대한 다 스타일드 컴포넌트로

  • 컴포넌트 네이밍

  • 컴포넌트를 감싸는 컴포넌트 : WrapperLayoutContainerBox

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

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


About

오직 글쓰기모임을 위한 커뮤니티 플랫폼

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published