Skip to content
badahertz52 edited this page Feb 3, 2025 · 11 revisions

🔧 기술 스택

  • 프레임워크 : Next.js
    • 도서에 대한 정보를 알려주는 페이지이기 때문에 빠른 렌더링,SEO, 이미지 최적화에 이점이 있어 선택
  • 라이브러리 : React, Typescript
  • 스타일 : SCSS(CSS module)
  • 린트 : Eslint
  • 테스트 : Storybook(컴포넌트 동작 확인)
  • 배포 : Vercel (Next.js 최적화, 간단한 CD 구축)
  • 기타 : MSW

SCSS(CSS module) 사용 이유

CSS-in-JS : Next.js에서의 한계점

1. 서버 컴포넌트에 사용하지 못함

CSS-in-JS의 경우 클라이언트 컴포넌트에서만 사용 가능하다. CSS-in-JS는 런타임에 js를 사용해CSS를 동적으로 만들기 때문에 서버 클라이언트에서 적합하지 않다.

2. 클라이언트 컴포넌트와 서버 컴포넌트 스타일링 방식 따로 설정의 번거로움

위의 이유로, CSS-in-JS 사용 시 클라이언트 컴포넌트와 서버 컴포넌트의 스타일링 방식을 다르게 해야해서 작업 효율이 좋지 못하며 예상치 못한 버그가 발생할 것 같다고 판단했다. 더욱이 처음 사용하고자 하는 Emotion의 경우 Context API를 기반이라, RootLayout를 클라이언트 컴포넌트로 변경하거나 클라이안트 컴포넌트에서만 ThemeProvider를 사용해야한다. theme을 편리하기 위해 사용할 수 있는 이점이 사라진 것이다.

SCSS(CSS module) 방식 선택

서버 컴포넌트, 클라이언트 컴포넌트에 모두 호환 가능하며 공통으로 사용하는 스타일 변수를 처리할 수 있는 방식을 찾았다. 그래서 CSS-in-CSS 중에서 사용할 만한 라이브러리, 프레임 워크를 찾았다.

Next.js 설치 시 기본적으로 물어보는 Tailwind CSS도 적용해봤지만, 스타일 코드와 프로덕션 코드가 분리되었으면 좋겠다는 점과 코드의 가독성 측면에서 적용하지 않기로 했다. 기존에 써본 경험이 있고 내장 기능으로 변수와 중첩이 용이한 SCSS와 함께 선택자명 중복을 피하기 위해 CSS module 방식을 선택했다.

보다 편리한 작업을 위해 추가로 설치한 라이브러기, 확장 프로그램

  • CSS Variable Autocomplete : VS Code 확장 프로그램으로 root에 선언한 변수 자동 완성을 도와준다
  • prettier-plugin-css : CSS 속성 자동 정렬
  • postcss : 스타일 최적화와 브라우저 호환성 관리 자동화
  • autoprefixer : CSS 속성에 필요한 브라우저 벤더 프리픽스를 자동으로 추가

Eslint 설정

코드의 오류를 사전에 방지하고 일관된 코딩 스타일을 유지하기 위해 설치한다.

설치한 패키지와 설치 이유

  • eslint: 코드의 문법 오류와 스타일 문제를 분석
  • @typescript-eslint/parser: TypeScript 코드를 ESLint가 이해할 수 있도록 파싱
  • @typescript-eslint/eslint-plugin: TypeScript 전용 린트 규칙을 제공하는 플러그인
  • eslint-plugin-react: React 관련 린트 규칙을 제공
  • eslint-plugin-react-hooks: React Hooks의 올바른 사용을 보장하기 위한 린트 규칙을 제공합
  • eslint-plugin-jsx-a11y: JSX 내에서 접근성(a11y)을 향상시키기 위한 린트 규칙을 제공
  • eslint-plugin-prettier: Prettier와 ESLint를 통합하여 코드 포맷팅과 린트를 동시에 수행
  • eslint-config-prettier: ESLint와 Prettier 간의 충돌을 방지하기 위한 설정을 제공

적용 범위

  • 스타일 코드,프로덕션 코드,테스트 코드 모두 타입스크립트로 구성되는 프로젝트이기 때문에, **/.ts 및 **/.tsx 파일에 대해 ESLint 규칙을 적용한다.

규칙

  • typeAlias과 interface 의 명명 규칙을 PascalCase로 강제
  • 모듈 임포트 순서를 정의 ➡️ 가독성을 높이고 유지보수를 용이하게 한다.

MSW 선택 이유

MSW를 선택한 이유

Node.js와 브라우저 환경에서 목 서버를 제공해, 서버 컴포넌트와 클라이언트 컴포넌트 모두에서 API 모킹이 가능하다. 환경 변수를 사용해 로컬 환경과 production을 구분해, 목 서버를 선택적으로 실행할 수 있다. 기존에 MSW로 목 서버를 구현한 경험이 있다.

Next.js의 API Routes를 활용한 모킹을 사용하지 않는 이유

프로덕션 코드에 모킹을 위한 코드를 두지 않기 위해서이다. API 요청 핸들러 마다 로컬 환경인지 여부에 따라 분기 처리를 해야한다는 번거로움, 모킹 코드와 구현에 필요한 코드가 함께 존재함으로써 생기는 가독성 문제와 모킹을 위한 코드고 빌드 파일에 포함되는 문제가 있다고 판단했다.