📚 프론트엔드 개발 문서

기술 스택

• 리액트
• 타입스크립트
• 웹팩
• ts-loader
• styled-components
  • props를 받아 동적 스타일링 가능
  • 스타일과 마크업이 같이 존재해서 UI복잡도가 높아져도 쉽게 CSS를 찾을 수 있음 → 가독성 높음+유지보수 쉬움
  • 런타임에 CSS 코드를 생성하므로 CSS in CSS와 비교하여 속도가 느리지만 아직 서비스 크기에 유의미한 차이는 보이지 않을 것이라 판단

서비스 타겟 환경 및 브라우저 지원 범위 선정

편의점으로 이동하면서 간편하게 볼 수 있게하기 위해 모바일을 우선적으로 지원하기로 결정
브라우저 지원 범위

코드 컨벤션

export 방식

• 컴포넌트는 export default
• hook은 export해서 index.ts에 정의하기

//correct
const Component=()=> {...};
export default Component;

export const func =()=>{...};

export const useHook=()=>{...};

//incorrect
export const Component=()=> {...};

이벤트 핸들러 네이밍

• 어떤 동작을 하는지 명시적으로 작성하기
• 네이밍: handle+동작(동사)
  • ex) handleLogin, handleRegisterForm

props 네이밍

• 컴포넌트 이름+Props

//correct
interface HeaderProps {};

//incorrect
interface Props {};

type vs interface

• 유니온 타입은 type
• 나머지 interface

//correct
type T = 'type' | 'example';
interface I {};

//incorrect
type T = {};

스타일 순서

display
	align-items
	justify-contents
position
	top right bottom left
float
width
height
margin
padding
border
background
font
color
text-decoration
text-align / vertical-align
white-space
other text
content
가상 선택자

import 순서

• eslint를 통해 정할 예정

styled-components

• 한 파일에서 마크업+스타일 정의
• 가장 큰 묶음은 XXContainer , 자잘한 것들은 XXWrapper

if문

• 한 줄 이더라도 중괄호 필수

//correct
if (ok) {
	return true;
}

//incorrect
if (ok) return true;

나머지 props 네이밍

const Component = ({ color, children, ...props }) => { ... }

스타일 분기할 때

const dividerSizeStyles = {
  'default' : css ``,
}

const dividerColorStyles = { ... };

storybook description

서술형으로 쓰기

color: {
	description: '컴포넌트의 색상입니다.'
}

style은 export 아래에

export default Component;

const Container=styled.div``;

interface에 jsdocs 추가

interface Props {
/**
 * 컴포넌트의 색상입니다.
 */
color?: Colors
/**
 * 컴포넌트의 길이를 나타냅니다.
 */
length?: string
}

컴포넌트의 타입 → variant로 네이밍 고정

interface Component {
	variant: 'outlined' | 'filled'
}

storybook meta

const meta:Meta<typeof Comonent> = { ... }

CSS Props

본인이 원하는 스타일 타입이 없을 때 컴포넌트를 이렇게 확장해 쓸 수 있다.

<Box
  css={`
    font-size: 16px;
  `}
/>;

StyleProps

interface ComponentProps {
	variant:
	border:
	color:
}

type StyleProps = Pick<ComponentProps, 'variant'| 'border' | 'color'>;

폴더 구조

📦src
 ┣ 📂apis
 ┣ 📂assets
 ┣ 📂components
 ┣ 📂constants
 ┣ 📂hooks
 ┣ 📂mocks
 ┣ 📂pages
 ┣ 📂router
 ┣ 📂styles
 ┣ 📂types
 ┣ 📂utils
 ┣ 📜App.tsx
 ┗ 📜index.tsx

TypeScript 컨벤션

우리 팀에서 typescript를 쓸 때 중요하게 생각하는 부분

최대한 타입 추론을 사용하기 중복되는 타입을 줄이기 위해 유틸리티 타입 사용하기

Component

선언방식 - 함수 표현식

//correct

const Component = () => {...};

Props - 컴포넌트 이름+Props

//correct

interface HeaderProps {};

//incorrect

interface Props {};

Props로 명시했을 때 모든 컴포넌트의 Props가 검색되어 찾기 어렵다. 따라서 컴포넌트 이름+Props로 정의해 보다 직관적으로 명시한다.

type vs interface - 유니온 타입은 type, 나머지는 interface 사용

//correct

type T = 'type' | 'example';
interface SomeThing {};

//incorrect

type T = {};

interface의 경우 확장이 가능하다.

Component with Children / Component without Children
컴포넌트 만들 때 ComponentPropsWithoutRef
children 받을 때 PropsWithChildren
리액트 표준으로 제공해주고 있고 간편하게 쓸 수 있다.

Event

// correct

const handleClick: MouseEventHandler<HTMLButtonElement> = (event) => { /*...*/ };

// incorrect

const handleClick = (event: React.MouseEvent<HTMLButtonElement>) => { /*...*/ };

이벤트 자체의 타입보다는 함수의 타입을 지정해 명시적으로 쓰고 싶어서 사용했다.

Hooks

기본 훅

const [data, setUser] = useState<User>();

현재까지는 위의 방식으로 쓰고 있지만 문제가 생긴다면 변경할 예정 Ref

const ref = useRef<HTMLElement>(null);

현재까지 ref는 돔객체에 접근하기 때문에 null로 초기화

모듈

type 관리 방식 types 폴더 아래에 common, products, review 등의 폴더를 만들어 사용 다른 타입들에 대해서는 딱히 prefix나 suffix를 사용하지 않음

type import/export
//correct
import type { Type } from '@/types/common';

//incorrect
import { Type } from '@/types/commmon';

lint를 사용하여 자동으로 type import가 되게끔 설정

API

Request / Response Type

api response의 경우 CategoryProductResponse와 같이 네이밍을 지음

const useCategoryProducts = (categoryId: number, sort: string = PRODUCT_SORT_OPTIONS[0].value) => {
  return useGet<CategoryProductResponse>(
    () => categoryApi.get({ params: `/${categoryId}/products`, queries: `?page=1&sort=${sort}` }),
    [categoryId, sort]
  );
};

빌드 설정

loader

ts-loader 사용

babel-loader가 속도는 더 빠르지만 타입 체킹을 하지 않는다는 점과 폴리필이 필요한 IE가 지원 종료되었다는 점을 고려하여 ts-loader로 결정함

{
  "compilerOptions": {
    "target": "esnext",
    "lib": ["dom", "dom.iterable", "esnext"], //컴파일 과정에서 사용되는 JS API와 같은 라이브러리를 지정
    "esModuleInterop": true,
    "module": "esnext", //컴파일을 마친 자바스크립트 모듈이 어떤 모듈 시스템을 사용할 지
    "moduleResolution": "node",  //node전략을 사용하여 모듈 탐색
    "resolveJsonModule": true, //json 파일 import 허용
    "forceConsistentCasingInFileNames": true, //파일 이름의 대소문자 구분
    "strict": true,
    "skipLibCheck": true, //라이브러리에 대해서는 타입 체킹x (컴파일 시간 줄일 수 있음)
    "jsx": "react-jsx", //tsx를 어떻게 컴파일 할 지 방식을 정함
    "outDir": "./dist",
    "typeRoots": ["node_modules/@types", "src/types"], //타입의 위치 지정
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    }
  },
  "include": ["src"], //컴파일에 포함
  "exclude": ["node_modules", "dist"] //컴파일에 제외
}