week7_1일차_PR

주요 작업

• 주간 계획 작성
• 컴포넌트 나눠서 설계해보기
• 기초 환경 세팅(번들링, ts, tailwindCSS, 파일 구조 등)

학습 키워드

• fsd
• 관심사 분리
• 번들링
• tailwindCSS

고민 및 해결과정

번들링 툴 선택

Vite를 이용한 이유는 개발 과정에서 결과를 확인하기 위해 빌드하는 작업 자체가 시간이 조금 걸렸기 때문에 보다 원할한 DX(개발자 경험)을 위해서는 Vite가 낫다고 판단하였다.

vite는 애플리케이션에서 사용하는 모듈에 대해 dependencies와 source code 두 가지의 범주로 나누어 개발 시작 시간을 개선한다.

dependencies의 경우 개발시 내용이 바뀌지 않을 사용하는 라이브러리의 의존성 번들링 과정을 수행한다. Vite는 Esbuild의 빌드 툴을 사용하여 번들링을 수행하는데, Esbuild의 경우 기존 webpack이나 parcel보다 100배 이상 빠른 속도를 보장한다.

Source code의 경우 우리가 대표적으로 사용하는 프레임워크의 확장자를 사용하면서 만드는 컴포넌트, 즉 Non-plain Js들의 소스코드를 의미한다. 해당 코드들의 경우에는 실행하기 위해서는 컴파일을 수행할 필요성이 있다. 하지만 기존의 번들링된 코드 기반 개발 서버는 개발하는 과정에서 소스 코드의 수정이 일어났을 때마다 통채로 다시 번들링하는 과정이 필요했기 때문에 불필요한 시간 소요가 발생했다.

이러한 문제를 느낀 Vite는 Native ESM 방식을 이용해서 개발 서버(Hot Reloading)를 구동한다. ESM 방식을 사용하는 방식의 장점은, import를 통해 동적으로 그때그때 필요한 파일들만을 가져온다는 점이다. 번들링을 하지 않고 개별 파일에 대해 트랜스파일링만 한 다음 이를 import하는 구조들을 통해 하나의 페이지를 완성할 수 있도록 만들었다.

따라서 나는 빠른 개발을 위해 vite를 선택했다

컴포넌트의 관심사 분리

기존에 내가 나누던 대로 컴포넌트를 나누어 보았다. 각 컴포넌트마다 필요한 이벤트와 어떤 data를 fetching해서 하위 컴포넌트에 props로 전달해주어야 할지를 적었다. 하지만 이제까지 내가 했던 프로젝트에서는 하나의 컴포넌트 안에서 ui, 비즈니스 로직, 데이터 처리 등의 모든 로직들이 얽혀있었다. 얽혀있어 가독성 또한 좋지 않던 탓에 오류 하나의 원인이 된 컴포넌트를 찾는 과정 또한 오래 걸리게 되었다. 따라서 나는 이번 프로젝트에서 컴포넌트 별로 ui, 비즈니스 로직, 데이터 처리와 같은 것들에 대해 모두 분리하고, 단일책임원칙(SRP)를 지켜가면서 설계를 다시 해볼 예정이다. 이러한 설계 과정에서 기능별로 나누고, 이를 조합하여 하나의 애플리케이션을 만들 수 있도록 하는 fsd 패턴을 적용하려 한다. fsd 패턴의 경우 기능별로 나누고, 디렉토리를 기반으로 관심사를 명확하게 나눌 수 있다는 점에서 보다 가독성과 기능별 확장 등이 용이하다고 판단했다. 따라서 위 컴포넌트를 기반으로 fsd 패턴을 이용하여 어떤 방식으로 나누어 볼 수 있을지에 대해서 설계중이다.