Skip to content

Week1 FrontEnd

Jump to bottom
김정훈 edited this page Aug 6, 2023 · 1 revision

FrontEnd

  • 사용기술 선택 CRA(Create React App) vs Vite
    • Vite는 최신 기술을 사용하여 개발 속도를 높여줌
      • 빌드를 위해 롤업 번들러를 활용하여 웹팩 기반의 CRA보다 더 작고 최적화된 번들링 가능
      • 로컬에서 개발할 때 번들링하지 않고 ESM 방식을 사용해 필요한 모듈만 로드하기 때문에 로컬 서버 구동 속도가 매우 빠름
    • 오래된 브라우저로는 새로운 JS기능을 실행하지 못하는데 호환성이 좋은 코드로 변환해줌

코드컨벤션: Airbnb Style Guide

  • 자바스크립트/타입스크립트 코드의 가독성, 일관성, 유지보수성을 향상시키기 위한 목적

ESLint에서 사용할 수 있는 유용한 규칙 중 몇 가지를 소개합니다. 이는 코드 스타일을 통일하거나 잠재적인 오류를 방지하는 데 도움이 되는 규칙들입니다:

  1. eqeqeq: == 대신 === 사용 권장
    • 설정: "eqeqeq": "error"
  2. no-var: var 대신 let 또는 const 사용 권장
    • 설정: "no-var": "error"
  3. no-unused-vars: 사용되지 않는 변수를 경고
    • 설정: "no-unused-vars": "warn"
  4. semi: 세미콜론 사용 강제
    • 설정: "semi": "error"
  5. quotes: 문자열에 작은따옴표(') 또는 큰따옴표(") 중 하나를 선택하여 일관성 유지
    • 설정: "quotes": ["error", "single"] (작은따옴표 사용), "quotes": ["error", "double"] (큰따옴표 사용)
  6. no-console: console.log() 등의 디버깅용 메시지 사용을 금지
    • 설정: "no-console": "warn"
  7. indent: 코드 들여쓰기를 위한 규칙
    • 설정: "indent": ["error", 2] (2칸 들여쓰기)
  8. no-extra-semi: 불필요한 세미콜론 사용 금지
    • 설정: "no-extra-semi": "error"
  9. comma-dangle: 객체 또는 배열의 마지막 요소 뒤에 콤마를 적용할지 여부를 지정
    • 설정: "comma-dangle": ["error", "never"] (콤마 사용 금지)
  10. no-trailing-spaces: 줄 끝의 공백 사용 금지
    • 설정: "no-trailing-spaces": "error"

이러한 규칙들을 ESLint 설정 파일에 추가하면 코드 스타일을 통일하고 오류를 사전에 방지하여 코드 품질을 높일 수 있습니다. 프로젝트에 맞게 적절한 규칙을 선택하여 사용하시면 됩니다.

  • Styled Component

    • 전역으로 사용할 color, font theme.tsx로 만들기
    • 디자인시스템, 환경설정…(eqeqeq …)
    • 라우터, 컴포넌트 설계
    {
	"option": [
		{
			"Title":"<hi>디젤</hi>2.2",
			"Price":"14000000",		
			"src":"어쩌구",
			"description":"저는 <hi>토크</hi>입니다"
		},
		{
			"Title":"가솔린",
			"Price":"14000000",		
		},
	],

}

function search(e){
	
}
    • 폴더구조
      • 스타일 파일은 컴포넌트, 페이지와 함께 배치
        • 스타일 폴더를 나누는 방법도 있지만 페이지를 개발할 때, 다른 폴더를 참조하며 개발하는 것은 불편
Front-End
	src
		api // api 모음 폴더
		component // 컴포넌트들
		assets //사용할 asset들
			images
			icons
			fonts
		pages // 페이지들
		hooks // hook모음집
		style
			theme.tsx
			reset.tsx
  • 모든 이슈에 아키택처, 컴포넌트 설계를 기본 작업으로 넣고, 태스크를 추가한다.
  • 페이지에서는 최대한 이벤트 등록을 하지 않는다. 컴포넌트 추상화 단위를 통일한다.
  • 컴포넌트의 이름은 명사하나로만 한다.

Docker 빌드 문제 발생

  • 개발 환경 설정 중 백엔드 팀 도커에서 프론트엔드 팀의 코드가 빌드되지 않는 문제발생
Error RUN npm run build

원인

  • 백엔드팀의 도커에서 지원하는 Node의 버전과 프론트에서 사용하는 TypeScript의 컴파일 JS(es2020)버전이 상이
  • 프론트엔드 파일 설정에서 TypeScript의 컴파일하는 JS버전을 쉽게 설정할 수 있어서, 프론트에서 버전을 낮추는 방법으로 해결

컴포넌트 구조 설계

  • 기능을 가지고 있거나 사용자에게 중요한 정보를 포함하고 있는 요소들을 기준으로 컴포넌트로 분리

image

Self
├─ Header
│  ├─ PageSwitcher
│  │  ├─ MainPageButton
│  │  └─ ModeChangeButton
│  └─ ContentSwitcher
│     ├─ HighlightButton
│     └─ ModelChangeButton
├─ OptionProgress
│  └─ OptionList
│     └─ Option
└─ Content
   ├─ SelectedOptionImage
   └─ SelectedOptionInfo
      ├─ OptionCardList
      │  └─ OptionCard
      │     └─ DetailInfo  
      └─ Footer
         ├─ ModalToggle
         ├─ SummaryModal
         └─ OptionSwitcher
            ├─ PrevOptionButton
            └─ NextOptionButton

구조 설계 근거

모듈화와 재사용성

  • 컴포넌트가 독립적으로 설계되고 구현되어 재사용이 용이
  • 유사한 기능이나 디자인 요소를 갖는 컴포넌트는 쉽게 재사용

유지보수성

  • 컴포넌트 단위로 파일이 구성되면 코드를 이해하고 수정하기가 훨씬 쉬움

가독성

  • 컴포넌트 구조를 따르면 프로젝트의 디렉토리 구조가 의미를 갖고 더욱 직관적
  • 코드를 이해하기 쉽고, 개발자들 간의 원활한 협업

확장성

  • 새로운 기능을 추가하거나 수정할 때, 해당 기능과 관련된 컴포넌트만 수정가능

디버깅 용이성

  • 각 컴포넌트가 독립적이기 때문에 버그를 추적하고 해결하는 것이 더욱 용이
  • 버그가 발생한 곳을 정확히 파악할 수 있으며, 해당 컴포넌트만 집중적으로 검사

HOME

Notion

API Docs

Swagger

Notion 링크

🏃‍♂️ Sprint

Week 1
Week 2
Week 3
Week 4

🛠️ Development

🤙 Ground Rule

Clone this wiki locally