기술 스택 논의사항

[turtle601]

기술 스택

1. Next.js (v15)

__Next를 사용하는 이유__

1. SEO 최적화를 통해 검색엔진 결과에서 상위에 노출, 브랜딩 효과를 극대화하기 위해
2. (vs React helmet) 리액트 helmet을 통해 seo 최적화를 일부 할 수 있지만 오픈 그래프 기능을 활용할 수 없음
3. 서버 컴포넌트를 통한 javascript 코드 최적화
4. v15에서는 버저닝, 빌드 최적화, 오픈 그래프 등 다양한 기능을 활용할 수 있음 

next v15 관련자료

고려사항: 러닝커브로 인한 개발 속도 지연

CSS 라이브러리

1. styled-component (좀 더 고려를 해보면 좋을 듯?)

1. 러닝 커브를 최소화, 쉽게 사용할 수 있는 라이브러리
2. CSS in JS를 통해서 동적 스타일링 할당이 가능 -> (vs `emotion`, `vanila extract`)

고려사항: Next에서 SSR를 지원하긴 하나, 권장사항은 아님 ( 아무래도 JS파일이다 보니, SSR 과정에서 스타일이 일부 적용이 안될 수 있음 )

vanila extract 관련 글
next 공식문서 styling

UI 라이브러리

1. radix ui

__Radix UI를 사용하는 이유__

1. 유연한 스타일링 ( Headless 설계 기반의 컴포넌트 라이브러리이기 때문 ) -> 커스터 마이징 하기 쉽다
3. 기본적인 접근성 지원 ( 키보드, 스크린 리더 등 )
4. Drop down 등 고도화된 UI 기능 제공
5. 다양한 CSS 라이브러리 호환 가능
6. 서버 사이드 렌더링 및 react 19 지원 ( radix ui는 Vanila CSS로 스타일링함 )
7. 코드 통일성 및 빠른 확장 가능

radix-ui react19관련 자료

그 외: headless/ui, shadcn/ui

클라이언트 상태 라이브러리

1. zustand

1. 컴포넌트 렌더링 최적화 기능 제공
2. 러닝 커브가 작고 상태 선언이 간편함
(vs redux) 보일러 플레이트 작성 해야함, 러닝 커브 up
(vs recoil) facebook에서 더 이상 개발을 진행하지 않음. 레거시 코드
(vs context api) 약간의 보일러 플레이트, 불필요한 렌더링이 발생할 수 있음

서버 상태 라이브러리

1. tanstack-query

1. 클라이언트 상태와 서버 상태를 명확하게 분리할 수 있다. (관심사 분리)
2. 서버 요청에 필요한 기능 (cache, statetime, refetch) 등을 쉽게 사용할 수 있다. 
3. (vs useSWR) mutation 관련 기능 및 더 정교한 cache 컨트롤이 가능하다. 
4. (vs Next fetch)  
- Next는 서버에서의 cache를 다루고 tanstack-query는 클라이언트의 캐시를 다룬다.
- 자동 패칭 및 로딩 및 오류 관리를 직접 관리해주어야 함

코드 스타일

1. eslint v9

__고려할 수 있는 플러그인__

1. rushstack/eslint-config
2. eslint-plugin-next + 알파

1) rushstack/eslint-config의 설명

• Microsoft가 관리함
• 최근에 만들어짐 (2021년 12월 첫 커밋)
• 독단적이지 않은 규칙
• 주석에 각 규칙에 대한 명확한 근거가 명시되어있음 (예시)
• 높은 코드 퀄리티와 상세한 문서
• eslint v9 지원
• 단점: next를 지원 안함

2) eslint-plugin-next

• next에서 제공하는 기본적인 eslint
• eslint v9
• 예시

3. prettier

module.exports = {
  printWidth: 80,
  trailingComma: 'all', // 기본값
  tabWidth: 2, // 기본값
  semi: true, // 일부 코드에서 라인의 시작 부분에 세미 콜론 추가
  singleQuote: true,
  bracketSpacing: true, // 기본값. true인 경우 {foo:bar}는 { foo: bar }로 변환됨
  arrowParens: 'always', // 기본값
  useTabs: false, // 기본값
};

아키텍처

1. FSD

1. 모듈화 및 유지보수성 향상
2. 의존성 관리가 용이 ( 예측 가능한 데이터 흐름 )
3. 테스트 용이성 (테스트 가능한 레이어와 아닌 레이어 분리를 통해 독립적으로 테스트 가능)
4. (vs Atomic) 레이어를 나누는 명확한 기준이 없어서 오히려 혼란을 줄 수 있다.

그 외

1. 상태 관리 라이브러리는 어떻게 사용하면 좋은가? 관련 자료

추가적으로 고려할 기술

1. MSW

• 백엔드와 독립적으로 개발 가능
• 별도의 mock 데이터를 관리해줘야 하는 문제