Skip to content

Latest commit

 

History

History
191 lines (150 loc) · 11.6 KB

README.md

File metadata and controls

191 lines (150 loc) · 11.6 KB

🏆 Wins 🏆

image

목차

  1. 프로젝트 소개
  2. 개발 기간
  3. 주요 기능
  4. 설치 및 실행방법
  5. 바로 가기
  6. 팀원 소개 및 개발 내용
  7. 기술 스택
  8. 디렉토리 구조
  9. 컨벤션
  10. FAQ

🚀 프로젝트 소개

React-wins는 기존 Wiz 정보제공 페이지를 개선한 프로젝트입니다.
사용자에게 원활한 서비스 제공을 위해 UI/UX를 개선하고, 새로운 기능을 추가하였습니다.

새로워진 Wiz 정보제공 페이지를 확인해보세요!


🖥️ 개발 기간

2024.09.02 ~ 2024.09.27


✨ 주요 기능


⚙️ 설치 및 실행방법

프로젝트 설치

npm install

프로젝트 실행

npm run dev

🖇️ 바로 가기


🧑🏻‍💻 팀원 소개 및 개발 내용

이승미 손지은 박지은 신동준
👑 이승미
(Front-end)
💵 손지은
(Front-end)
박지은
(Front-end)
신동준
(Front-end)
1. 깃허브 repo 초기세팅
2. 프로젝트 초기세팅(ESLint, Prettier, 필요 패키지 설치)
3. 초기 라우터 설정
4. 공통 레이아웃(Header, nav, footer, main, tab, breadcrumb, banner) 초기 설계 및 마크업
5. Home 공통 컴포넌트 설계 및 마크업
6. [Home]-[gameSchedule] 섹션 마크업 및 데이터 패칭
7. [kt wiz]-[kt wiz는?] 페이지 마크업
8. Game 공통 컴포넌트 설계 및 마크업
9. [Game]-[경기일정], [관전포인트] 페이지 마크업 및 데이터 패칭
10. date-fns 라이브러리를 활용하여 캘린더 구현
1. [Home]-[gallery] , [video] 섹션 마크업 및 데이터 패칭
2. [Media]-[wiz소식], [wiz보도자료] 페이지, 상세페이지 마크업 및 데이터 패칭(페이지네이션 구현)
3. [Game]-[순위기록]-[팀순위] 페이지 마크업 및 데이터 패칭
4. 목업데이터 세팅 및 배포 진행
5. 공통 컴포넌트 생성 및 리팩토링
6. 네비게이션 스타일링 및 라우터 리팩토링
7. 기타 페이지 구현 (회원정책, 입장 및 좌석정보)
8. 전체 코드 정리 및 리팩토링
1. [Wiz park]-[수원 kt wiz park] 페이지 마크업
2. [Player]-[응원단] 페이지 마크업 및 데이터 패칭
3. [game]-[순위기록]-[관중현황]페이지 마크업 및 데이터 패칭
1. [Wiz park]-[수원 kt wiz park] 페이지 마크업
2. [Player]-[응원단] 페이지 마크업 및 데이터 패칭
3. [Game]-[박스스코어] 페이지 마크업 및 데이터 패칭
4. Vercel 자동 배포 진행
5. Player 공통 컴포넌트 생성 및 리팩토링, 차트 구현
6. api 모듈 설계
7. TanStack Table 기본 로직 설계
8. TanStack Query 적용 및 리팩토링

🛠️ 기술 스택

기술스택

Front-end Cooperation Tool Deploy
TypeScript Vite React Styled-components Zustand Axios Echarts Tanstack-table Tanstack-query Swiper React-router KaKaomap API Slack Discord ESLint Prettier Git Github Notion Figma Postman Github Vercel

📂 디렉토리 구조

react-wins
    ├─ public
    │  └─ favicon.svg
    ├─ src
    │  ├─ api
    │  │  └─ api.ts
    │  ├─ assets
    │  │  ├─ icons
    │  │  └─ images
    │  ├─ components
    │  ├─ data
    │  ├─ hooks
    │  ├─ layouts
    │  ├─ pages
    │  ├─ router
    │  ├─ store
    │  │  ├─ actions
    │  │  └─ types
    │  ├─ styles
    │  ├─ types
    │  ├─ utils
    │  ├─ main.tsx
    │  └─ vite-env.d.ts
    ├─ README.md
    ├─ eslint.config.js
    ├─ index.html
    ├─ package-lock.json
    ├─ package.json
    ├─ tsconfig.app.json
    ├─ tsconfig.json
    ├─ tsconfig.node.json
    └─ vite.config.ts

📌 컨벤션

1. Commit

기본 구조 : [type]: 커밋 내용

  • 각자가 맡은 Task가 구체적으로 정리되어있어야 한다.
  • 개발을 하다 겪은 문제들이 Github Issue로 잘 정리되어있어야 한다.
  • 한 commit당 하나의 기능 구현만 해야한다.
[type]

feat: 기능 (feature)
fix: 버그 수정
docs: 문서 작업 (documentation)
style: 포맷팅, 세미콜론 누락, 구분지을 타입이 없을 때 등.
refactor: 리팩토링 코드
test: 테스트
chore: 관리(maintain), 패키지 설치, 핵심 내용은 아닌 잡일 등
design: 스타일링 및 마크업

2. Branch

Github-flow 전략을 기반으로 한다.
[main], [development] 브랜치와 각 기능별 [feature] 보조 브랜치를 운용

  • main : 배포 단계에서 사용하는 메인 브랜치
  • development : 개발 단계에서 각 기능을 병합하는 브랜치
  • feature : 기능 단위로 독립적인 개발 환경을 위해 사용하는 브랜치

3. Pull Request, Issue

Code Review 후 approve 상태로 전환되었을 때, 상위 브랜치로 병합한다.
정해진 또는 알맞은 템플릿을 사용하여 양식에 맞게 작성한다.

4. Code, Style, Type

Code

  • eslint, prettier 설정을 통해 코드 컨벤션을 정한다.
  • 정해진 규칙에 따라 자동적으로 코드 스타일을 정리하여 일관성을 유지한다.
  • 코드 품질 관리는 eslint, 코드 포맷팅은 prettier에 일임하여 사용한다.
  • 예외 규칙은 팀원과의 논의를 통해 정한다.
  • 협업 시 빠르게 개발하는데에 목적을 둔다.

함수 정의

const Sample = () => {
 return (
   <>
     <h1>Sample Component</h1>
   </>
 );
}
export default Sample

스타일 코드, 타입 정의

  • 코드의 위치는 컴포넌트 선언 상단에 위치한다. (타입 정의 - 스타일 코드 - 컴포넌트 선언 순)
  • 정해진 네이밍 규칙을 따른다.

❓ FAQ