피그마로 전체적인 웹(애플리케이션)의 프로토타입이 완성되었다.
또, 프로젝트 시작을 위해 폴더 구조를 어떻게 해야 할지 얼추 정하였다.
최종적으로 결정된 폴더 구조는 다음과 같다.
📦 client
└─ src
├─ components
│ ├─ commons
│ │ └─ (공통적으로 사용하는 컴포넌트)
│ └─ (페이지 폴더)
│ └─ (페이지에서 사용하는 컴포넌트)
├─ pages
│ └─ (페이지 파일)
├─ services
│ └─ (도메인 별로 나눈 서비스 파일) // axios로 서버에 데이터 요청
├─ hooks
│ └─ (커스텀 훅)
├─ recoils
│ └─ (데이터 별 atom과 selector를 합친 파일)
├─ stores
│ └─ (React Query를 사용해 가져온 데이터를 저장하는 파일)
├─ utils
│ └─ (hook 외의 공통적으로 사용하는 함수 파일)
└─ constants
└─ (상수 파일)
components
컴포넌트를 나누는 기준까지는 개발을 하면서 생각해봐야 하겠지만, 어쨌든 자주 사용되는 공통 UI를 저장하는 폴더이다. commons 폴더의 경우 둘 이상의 페이지에서 사용되는 컴포넌트를 저장한다. 보통 header, footer, navbar 등을 commons 폴더에 저장하는 것 같다. 그 외의 컴포넌트는 모두 한 폴더 안에 작성하는 것으로 생각했는데, 코치님께서 페이지 별로 사용하는 컴포넌트를 구분하자는 의미에서 폴더를 나누자고 하셨고, 그것이 개발하는 데 보기 좋을 것 같아 구조를 변경하기로 했다.
pages
하나의 페이지 파일이다. 메인 페이지, 상세 페이지, 로그인 페이지 등... 필요에 따라 페이지 파일도 분리 될 경우가 있을까? 확신할 수 없다.
services
서버에 데이터를 요청하는 로직을 따로 담아 둔 파일이다. 데이터 요청의 경우 처음엔 fetch를 사용하기로 했는데(아무래도 모두에게 익숙한 함수여서) 코치님께서 결국은 axios를 사용하는 것이 좋다고, fetch와 axios의 차이점을 알아보는 것이 좋겠다고 하셨다.
Axios와 Fetch의 차이점
| Axios | Fetch |
| request 객체에 url를 갖는다. | request 객체에 url이 없다. |
| 설치가 쉬운 독립적인 서드파티 패키지이다. | 현대 브라우저에 기본적으로 내장되어 있다. |
| XSRF 보호 기능이 내장되어 있다. | XSRF 보호 기능이 없다. |
| data property를 사용해 데이터를 전송한다. | body property를 사용해 데이터를 전송한다. |
| data는 객체를 가진다. | body는 문자열로 변형되어 보내진다. |
| JSON 데이터로 자동 변환이 가능하다. | json() 메서드를 이용해 JSON 데이터를 받아와야 한다. |
| 응답 취소 및 타임아웃 설정이 가능하다. | 응답 취소 및 타임아웃 설정이 불가능하다. |
| HTTP 요청을 인터셉트할 수 있다. | 요청을 인터셉트하는 방법이 제공되어있지 않다. |
| GET 요청 시 data property를 무시한다. | GET 요청 시 body에 데이터 첨부가 가능하다. |
| 상태 코드가 404또는 500일 때도 Promise 반환이 거부되지 않고, ok값이 false로 변한다. |
|
| credentials의 초기화 옵션을(include로) 설정하지 않는다면, 오리진을 포함한 Cookie를 전송하지 않는다. |
|
| 예전 브라우저 버전을 사용하는 경우, Cookie/유저 로그인 상태의 영향을 받을 수 있는 가능성이 있는 모든 API 요청에 'same-origin'을 초기화 옵션으로 설정한 인증 정보를 포함해야 한다. |
예전에 정리한 차이점이 있긴하다.
그러나 어느 것이 명백한 장점인지는... 잘 모르겠다.
아마 fetch로도 불편함 없이 기능을 구현해왔어서 그랬던 건 아닐까...
찾아보니 fetch는 자바스크립트에 기본적으로 내장된 함수여서 axios보다 복잡한 기능을 수행하지 못한다고는 한다😅
hooks
훅과 이벤트 함수, 컴포넌트를 구분하기 위해 컴포넌트 파일에서 훅을 따로 분리해야 하는 것으로 알고 있다.
아직까지 훅에 대한 개념조차 헷갈리는데, 그만큼 많이 작성해야 감이 올 수 있을 것 같다.
recoils
전역 상태 관리 라이브러리로 recoil을 사용하는 것으로 결정이 되었다. 처음엔 recoil이 페이스북의 지원을 더이상 받지 않는다는 얘기가 있어서, 그럼 zotai나 zustand로 넘어갈까 하는 얘기가 나왔었는데(둘 다 러닝커브가 그렇게 높지 않다는 얘기도 나왔고), 한국어로 된 문서가 별로 없다는 점에서 공부만 하는데 너무 큰 시간을 쓰지 않을까라는 생각이 들어 그나마 사용해 본 recoil을 사용하기로 했다. 그 얘기는 그렇다치고, 폴더 구조와 관련해선 데이터 별로 atom과 selector를 하나의 파일 안에 작성하기로 했다. 내가 생각했던 이유는 atom과 selector 모두 파일 밖에서 사용할 땐 useRecoilState나 useRecoilValue 등으로 가져오는데, 그렇다면 굳이 구분할 필요가 있냐는 것이었다. 그러나 구현을 하면서 바뀔 가능성도 있을 것 같다.
stores
React Query를 사용해 데이터를 가져오고 수정하는 파일을 저장한 폴더이다. 사실 React Query의 경우 헷갈렸던 것이, 나는 일단 모든 서버 데이터를 가져올 때는 React Query를 사용한다고 생각했다. 캐싱 기능도 지원하고, 서버에서 가져온 데이터를 관리하는 데 가장 많이 사용하는 라이브러리인데 안 쓸 이유가 있나? 라는 것이었다. 그러나 코치님께서 React Query의 경우 변화가 많지 않은 데이터를 서버에서 가져올 때, 캐싱을 하여 페이지 접속 시마다 API 요청을 하지 않기 위해서 사용한다고 하셨다. 그래서 굳이 그런 데이터가 존재하는 것이 아니라면 recoil만 사용해도 되지 않을까, 라고 하셨는데... (잘못 이해했을 수도 있다.) 결국은 React Query를 사용하는 것으로 결정이 되었고 (일단은 사용해보면 좋을 것 같다.) 아마 그 작업을 위한 폴더가 될 것 같다.
utils
리액트의 라이프사이클에 영향을 주는 함수를 사용하는 경우엔 훅, 아닌 경우엔 utils 폴더에 공통된 함수 파일을 폴더에 저장하는 것으로 알고 있다.
constants
공통적으로 사용하는 상수를 저장하는 폴더이다. 나 같은 경우 에러 코드에 대해 사용자에게 보여줄 메시지를 constants에 저장했었는데, 코치님께서 그 경우엔 react-error-boundary 라이브러리를 사용하면 될 것 같다고 하셔서, 어떤 상수를 저장하게 될 지는 구현을 하면서 알게될 것 같다.
#엘리스트랙 #엘리스트랙후기 #리액트네이티브강좌 #온라인코딩부트캠프 #온라인코딩학원 #프론트엔드학원 #개발자국비지원 #개발자부트캠프 #국비지원부트캠프 #프론트엔드국비지원 #React #Styledcomponent #React Router Dom #Redux #Typescript #Javascript
