[리팩토링 배경]
팀 프로젝트로 Open API를 활용한 날씨에 어울리는 칵테일 추천 서비스를 3주간 제작했었다. 당시 React-redux 소양이 부족하여 redux 없이 프로젝트를 구현했었는데, 이번 기회에 react-redux-toolkit 를 활용해 version.02로 프로젝트를 업그레이드 해보고, 리팩토링을 시도하며 얻게 된 인사이트를 정리해보고자 한다.
당시 구현한 기능과 본인이 담당한 기능은 다음과 같다:
1. 메인페이지 - 본인 참여
- 날씨에 어울리는 랜덤 칵테일 추천(재추천 기능 포함)
- 칵테일 정보 구글 검색 연동
2. 메인페이지 칵테일 제조법 상세 페이지
3. 옵션 별 랜덤 칵테일 추천 페이지
4. 날씨 별 칵테일 모아보기 페이지
5. 칵테일 퀴즈 페이지
[개발환경]
React.ts, TypeScript, SCSS
[배운점- 디렉토리 구조의 중요성]
version.01 에서는 다음과 같이 디렉토리를 구성했었다.
src
|- components
| |- Home
| |- CocktailMatch.tsx
| |- CocktailMatch.module.scss
| |- WeatherToGlass.tsx
| |- WeatehrToGlass.module.scss
|- pages
| |- Home.tsx
|
|- App.tsx
|- Index.tsxHome 폴더 안에 세부 기능별로 파일을 분리하고 CocktailMatch 라는 파일에서 각 기능 파일을 불러왔다. 그리고 Home.tsx 페이지에서 CocktailMatch 파일을 불러와 렌더링 하는 구조였다. 일단 본인이 제작했음에도 파일명에서 어떤 기능을 수행하는 지 유추하기가 어려웠다. 또 상위 컴포넌트에서 하위로 props를 내려주는 구조에서 데이터의 흐름을 한 눈에 파악하기 어려운 문제점이 있었다. 이 때문에 결론적으로 유지보수에 안 좋은 코드였다고 판단된다.
version.02 에서는 다음과 같이 디렉토리 구조를 개편했다:
src
|- app
| |- hooks.ts
| |- store.ts
|
|- components
| |- Home
| |- getCocktail
| |- getCocktail.interface.ts
| |- getCocktail.tsx
| |- WGobject.tsx
| |- getWeather
| |- getWeather.tsx
| |- makeBtns
| |- makeBtns.interface.ts
| |- MakeBtns.tsx
| |- home.module.scss
|
|- features
| |- cocktailSlice.interface.ts
| |- cocktailSlice.ts
| |- weatherSlice.interface.ts
| |- weatherSlice.ts
|
|- pages
| |- Home.tsx
|
|- App.tsx
|- Index.tsx
[수정된 디렉토리 특징]
- 기존 Home 컴포넌트 폴더가 단일로 존재하던 것에서 기능별로 하위 폴더를 3개 생성하였다. 하위 폴더는 각각 weather와 관련된 d액션을 dispatch 하는 기능, cocktail 관련 액션을 dispatch 하는 기능, 버튼 UI를 그리는 역할을 담당한다. 이렇게 한 이유는 각 폴더가 상하위 구조를 가지고 있어 데이터 흐름상 분리하여 파악하기 쉽기 때문이다. (데이터 흐름: Weather -> Cocktail -> Btns)
- 코드 가독성을 위해 인터페이스 별로 파일을 분리하였다.
- createAsyncThunk를 활용하여 API 통신 등 비동기를 수행하는 부분은 따로 features 폴더에 slice로 분리하였다. 이렇게 되면 각 컴포넌트 내에서는 비동기를 직접 수행하지 않고 slice 파일 내에 정의된 비동기 통신 함수를 호출하여 사용하여 가독성이 높아진다.
- 1에서 서술된 대로 데이터 흐름상 GetWeather 컴포넌트가 나머지 하위 컴포넌트를 리턴하므로 Home.tsx 에서는 GetWeather 컴포넌트 하나만 import 한다.
- store를 생성하고 features 폴더 내 weatherReducer와 cocktailReducer를 등록한다.