PICK!PLE

내가 PICK!한 바로 '그 사람'과 함께하는 클래스 모임

💁 서비스 소개

🔨 서비스 주요 기능

호스트

게스트

👩🏻‍💻🧑🏻‍💻 PICKPLE Developers

팀원	박채연	유태승	임화랑	장정안
팀원 소개
역할	WEB FRONTEND	WEB FRONTEND	WEB FRONTEND	WEB FRONTEND

🛠️ 기술 스택

Node.js Version

v20.15.0 (LTS version as of 2024.07.01)

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

📚 주요 라이브러리

• "react": "^18.3.1",
  

• "react-router-dom": "^6.24.0",
  

• "@emotion/react": "^11.11.4",
  

• "eslint": "^8.57.0",
  

• "jotai": "^2.9.0",

  
  
  

🗂️ 프로젝트 폴더 구조

폴더 구조 보기

|-- 📁 node_modules
|-- 📁 public
    |-- 📁 image
    |-- 📁 svg
|-- 📁 src
    |-- 📁 apis
        |-- 📁 domains
        |-- 📁 queryKeys
        |-- api.ts
|-- 📁 asset
        |-- 📁 lotties
        |-- 📁 svg
    |-- 📁 components
        |-- 📁 common
            |-- 📁 Button
                |-- Button.tsx
                |-- Button.style.ts
            |-- index.ts
    |-- 📁 constants
        |-- 📁 images
        |-- 📁 mocks
        |-- index.ts
    |-- 📁 hooks
    |-- 📁 pages
        |-- 📁 class
            |-- 📁 components
            |-- 📁 types
            |-- 📁 hooks
            |-- 📁 page
    |-- 📁 routes
        |-- homeRoutes.tsx
        |-- adminRoutes.tsx
        |-- index.ts
    |-- 📁 stores
        |-- 📁 types
        |-- index.ts
    |-- 📁 styles
        |-- global.ts
        |-- reset.ts
        |-- theme.ts
    |-- 📁 types
        |-- 📁 api
            |-- 📁 schema
                |-- index.ts
        |-- index.ts
    |-- 📁 utils
        |-- index.ts
|-- App.tsx
|-- main.tsx
|-- .eslintrc.json
|-- .gitignore
|-- .prettierrc
|-- README.md
|-- package.json
|-- tsconfig.app.json
|-- tsconfig.json
|-- yarn.lock

📏 컨벤션

1️⃣ Coding

변수

• var 금지.
• const → let 순서로 위부터 선언.
• 변수를 조합하여 문자열 생성시 “+ “ 금지. → 리터럴 사용(백틱 ```)
• 상수는 영문 대문자 스네이크케이스 : API_KEY
• 변수명 : 의미를 확실히 나타낼 수 있도록
  • 예시 : 배열에 Arr 보다는 변수s = fruits, userlists 등등
• 줄임말 쓰지말기. 이름이 길어지더라도 어떤 변수인지 정확하게
• 만약 변수에 할당되는 값이 boolean인 경우에는 is를 접두사로 붙인다.
  • isActive 같이 is 키워드는 boolean에만 적용
• map 사용시 변동되는 리스트라면 key값을 고유하게 잘 설정해주기 index사용금지
  • 서버에서 내려주는 id값 or uuid 사용

함수

• 화살표 함수. function 키워드 쓰지말기
• 함수명 : 어떤 일을 하는지 명확히 묘사. 동사+명사의 형식.
  • get : 어떤 값을 얻는 함수
  • create : 갖고 있는 변수를 활용, 새로운 값과 변수를 만듦
  • check : 함수 안의 로직을 확인.
  • 그외, 기능을 분명하게 드러내도록 네이밍
• 이벤트 핸들링 함수는 handle 로 시작. 그 외에는 금지.
  • 예시: handleResetClick, handleSubmitClick
• 유틸함수는 반환값을 기준으로 이름 네이밍
  • boolean값 반환시 has—- ex) hasEmail = email이 존재하는지 여부를 반환하는 함수
• 중복함수는 utils 폴더에 모아서 재사용한다.

컴포넌트

• rafce

• 리액트 컴포넌트만 PascalCase 사용 : PascalCase

  • 그 외에는 camelCase ex) type, d.ts파일, ts파일

• 타입 Interface 선언시

  • 컴포넌트의 인자 : ~Props (ex. HomeProps, AdminProps)
    • 이때의 Interface는 type 폴더로 분리 금지
  • ex) MainComponent interface 선언시 = MainProps

• props명은 camelCase 대문자시 문제 생김

• 의미없는 div 또는 컴포넌트 최상단은 fragment 사용하기

  const InfoText = () => {
    return (
      <>
        <h1>Welcome!</h1>
        <p>This our new page, we're glad you're are here!</p>
      </>
    );
  };

• children이 불필요할 땐 selfClosing사용하기 <Component />

폴더명

• 무조건 소문자로 시작하기!
• 뒤에 s붙이기
• 카멜케이스!

타입

• object → interface
• 단일변수 → type
• 컴포넌트 인자에 대한 타입은 컴포넌트 상단에
• 그 외의 타입들은 types 폴더에(컴포넌트 인자에 배열or객체 등이 있다면 이 타입도 types 폴더로)
• prop의 타입명은 OOOProps
• api response 타입명은 OOOResponseTypes

메소드

• 배열 복사시 → 스프레드 연산자(…) 사용

  • const copys = […originals]

• for 보단, forEach/map을 사용

• 구조 분해 할당을 적극 이용

  interface userDataProps {
    userName: string;
    userBirth: string;
  }
  
  function checkIsUser({ userName, userBirth }: userDataProps) {}

• 불필요한 반복문 지양 : filter, array.include() 등

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

Style

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

• Emotion

  • css 객체 스타일링 사용
  • style 파일을 분리
  • 선택자 사용하지 않기, className 사용하지 않기 → 최대한 다 css 객체로

• color & font 사용시 :

  ${({theme}) ⇒ theme.colors.main} (x)
  
  //theme 직접 import 후
  `${theme.colors.main}` (o)

• 스타일드 컴포넌트에서 prop를 이용할 때는 transient prop 사용 : $로 시작하는 props로 내려줌.

  <p $isAsap={checkIsAsap}>ASAP이라면 파란색</p>

• 단위는 rem을 사용, 변경이 필요없는 (border관련) 속성만 px

• CSS

• CSS 클래스 이름 : 케밥 케이스 (it-is-kebab-case)

2️⃣ Git & Github

Git Flow

• main: 제품을 배포하는 브랜치
• develop: 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 Merge
  • develop 브랜치를 기준으로 feature 브랜치를 분기하고, 각 feature 브랜치를 합침
  • develop 브랜치에서 main 브랜치로 병합
• feature: 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 Merge
  • 반드시 develop 에서 분기해야 됨. 분기 된 다른 feature 브랜치에서 또 다른 feature 브랜치를 분기하면 절대 안됨.

현 프로젝트에서는 release, hotfix 브랜치는 사용하지 않음.

브랜치 생성

기능 구현 전 자신이 구현할 부분을 이슈로 관리

1. 이슈템플릿 을 활용하여 이슈 생성
2. 1에서 생성된 이슈 번호를 이용하여 브랜치 생성.
   1. 브랜치 이름은 feat/#<issued number>/example ex) feat/#18/common-button

작업

모든 작업은 develop 에서 분기된 feature 브랜치에서 진행

• 커밋 메시지는 커밋유형: <구현, 수정, 개발한 내용에 대한 커밋 메시지> (#<issued number>) ex) feat: Button 공통 컴포넌트 제작 (#18)

  커밋유형	의미
  feat	새로운 기능 추가
  fix	버그 수정
  docs	문서 수정
  style	코드 formatting, 세미콜론 누락, 코드 자체의 변경이 없는 경우
  refactor	코드 리팩토링
  test	테스트 코드, 리팩토링 테스트 코드 추가
  chore	패키지 매니저 수정, 그 외 기타 수정 ex) .gitignore
  design	CSS 등 사용자 UI 디자인 변경
  comment	필요한 주석 추가 및 변경
  deploy	배포 관련
  setting	개발 환경 세팅

브랜치 병합

feature 브랜치에서 develop 브랜치로 merge할 때는 PR을 이용함 (직접 merge ❌)

1. develop, feature 브랜치 최신화

2. develop → feature merge 하고 충돌 처리

   • feature 브랜치로 checkout 해서 git merge develop

3. PR템플릿 을 활용하여 PR 작성

   • PR 작성시 이슈번호 제대로 기입해야 이슈가 함께 닫힘(템플릿대로 하면 됨)
   • 팀원들의 review & approve(2명) 후 스쿼시 머지

   주의⚠️ - review & approve 과정에서 다른 PR 머지 등 develop에 수정사항이 생겼다면, 2번과정을 다시 해줘야 함.

4. 정상적으로 머지 되었다면 feature 브랜치 삭제

📝 픽픽이들의 아티클

• [TS] type 아직도 일일이 만드시나요? - 태승
• 뚝딱뚝딱 공통 컴포넌트 만들기 - 채연
• 리액트 쿼리 간지나게 사용하는 법 - 정안
• [Funnel] 퍼널구조를 통해 여러 단계의 입력폼 다루기 - 화랑

---