시연 영상 바로가기
⚽ 초기 목표와 결과 비교
⭕ 달성한 것
recoil에 대한 이해
- recoil에 내장된 훅을 대부분 사용해보았고, recoil이 왜 react에 최적화된 상태 관리 라이브러리인지 이해할 수 있었다.
- 이전에 redux를 사용해봤기 때문에, redux와의 장단점을 비교해볼 수 있었으며 각 라이브러리는 전역 상태 관리에서 어떤 점을 중점적으로 바라보았는지 그리고 전역 상태 관리가 왜 중요한 지 다시 한 번 학습했다.
react에 대한 이해
- next.js를 사용했던 이전 프로젝트와는 다르게 순수 react로 프로젝트를 완성했다. CSR과 SSR의 차이점을 이해할 수 있었다.
- react-router-dom, react v18의 훅 등을 깊게 이해해볼 수 있었고 적극적으로 활용하려고 노력했다.
-
특히, 이번 프로젝트에서는 react-router의 location을 활용하여 params를 기반으로 전역 상태를 관리하고 제어하였는데, 개인적인 체감으로는 코드가 직관적이고 분산되지 않아 좋다고 느꼈다.
-
react v18의 Suspense의 경우, recoil 때문에 사용하게 됐는데 비동기 작업 시 로딩창이라거나, 로딩 스피너 등을 suspense를 활용하여 간단하게 띄울 수 있어서 앞으로의 코딩에서 효율적으로 사용할 수 있을 것 같다고 느꼈다.
- Suspense와 react lazy를 통해 코드 스플리팅을 적용할 수 있다고 학습하였고, 다음 프로젝트에서 활용해보고 싶다.
-
css
- UI 프레임워크없이 모든 CSS를 직접 구현했다.
- 각종 색상, box size, font size 등 일정한 수치나 색상을 theme 변수로 관리하여 css에 적용될 수 있도록 했다. 이 부분에서는 재사용성이라거나, 통일성 면에서는 효율적으로 코딩했다고 생각한다.
모바일, 브라우저 대응
- 100% 반응형 웹은 구현하진 못했지만 react-device-detect 라이브러리를 활용하여 모바일과 브라우저의 동작 방식이나, 컴포넌트를 약간 다르게 구성했다.
- 모바일의 경우, 하단 Nav바를 띄운다던지, swipe 기능을 넣는다던지 등
❌ 달성하지 못한 것
recoil의 장점 극대화
- recoil의 장점이자 단점이라고 평가되는 캐싱 기능에 대해서는 깊게 연구해보지 못했다.
- selector가 구독하고 있는 atom이 변하지 않는다면 같은 불필요한 API를 요청하지 않고, 캐싱된 값을 반환해주는 원리인데, 이를 활용하여 통신 비용을 절감할 수 있지만, 반대로 특정 시간, 특정 조건에 값을 갱신해야 하는 상황을 재현하지는 못했다.
- redux에서 recoil이나, react-query로 넘어가는 이유 중 하나가 캐싱 부분(RTK도 query기능을 지원한다)인데 recoil에서 이 부분을 적극적으로 실험해보지 못한 점이 아쉽다.
성능 관리
- 성능 측정에 대해서는 미흡한 부분이 있었다. 중간에 협업을 하던 백엔드 개발자분의 부재로 인해 배포로 연결되지 못하여 제대로된 성능을 측정해볼 수 없었다는 점이 아쉬웠다.
- 브라우저로도 충분히 가능했을 것 같지만, 기능 구현에 초점이 더 맞춰져 있었기 때문에 성능 측정에 대해 신경을 쓰지 못했던 것 같다.
- 재렌더링에 대해서는 최대한 신경을 썼던 것 같다. 전역 스코프에 console을 찍어보면서 재렌더링이 되는 횟수와 그 원인에 대해 최대한 이해하려고 노력했다.
- 예를 들어, 내가 생각하는 특정 상호작용에서의 재렌더링 횟수와 실제 재렌더링 횟수가 차이난다면 그 원인을 무조건적으로 짚고 넘어갔다.
- useEffect를 굉장히 많이 사용한 프로젝트였는데, useEffect가 unmount될 때 clean-up함수를 작성해보지 못한 것도 아쉽다. 당장의 기능 상에서는 큰 문제가 없었기 때문에 넘어갔지만, unmount상황에서 useEffect의 실행으로 인해 의도하지 않은 동작이 발생할 수 있기 때문에 앞으로의 코딩에서 신경써야 하는 문제이다.
pwa 못해본 것
- 이 또한 백엔드 개발자 분의 초반 탈퇴로 인해, 배포까지 이어지지 못했기 때문에 PWA는 포기했다. 하지만 PWA 전환은 크게 어려워 보이진 않아서 다음 프로젝트 때 해보고 싶다.
프론트엔드 개발자답게 코딩하는 것
- 프로젝트를 시작하며 정의내렸던 성능, 코드 가독성, 객체/함수 지향적을 의식하며 코딩한다는 목표에 만족할만큼 하지 못했다.
- 코드 가독성에는 신경을 굉장히 많이 썼고, 함수와 컴포넌트를 계속해서 분리하며 코드의 응집도라거나 재사용성에 대해서는 코딩 초보인 것치고는 자신있다고 생각하지만 이외의 부분에 대해서는 신경쓰지 못했다. 정확히는 어떻게 해야할 지 감이 잘 안 잡혔다.
- 디자인 패턴은 알지만 어떨 때 사용해야 하는지, 내가 짠 알고리즘 코드가 효율적인지, 어떤 코드가 객체/함수 지향적인지 아직은 잘 모르겠다. 이 부분은 실 서비스에서 운용되는 코드를 보면 쉽게 이해될 것 같은데 좀 아쉽다.
🖐 구현한 기능
로그인 / 회원가입
- 이제는 사용에 익숙해진 react-hook-form을 다시 한 번 활용하여 구현했다.
- 백엔드 api를 통하지 않기 때문에, local storage를 활용하여 임시로 로그인을 구현했다.
깃헙 링크
로그인 폼 컴포넌트
회원가입 폼 컴포넌트
지도
지도 생성 / 마커 생성 / 마커 하이라이트 / 지도 이벤트(클릭, 드래그, 줌인아웃 등)
- Naver Map Api를 적극적으로 활용하여 기능을 구현했다.
- 단순히 패키지를 다운받아서 사용한다는 것과는 많은 차이가 있었다. naver map에 있는 수많은 api 중에서 내가 원하는 api를 찾고 코드 예제를 보면서 직접 내 코드에 적용한다는 점이 어려웠고 재밌었다.
야영장 정보, 내 정보 Drawer
- drawer는 params를 기반으로 전역 상태가 변경되며 전역 상태에 의해 다른 컴포넌트를 띄우게 했다
- 동시에 브라우저, 모바일 기기를 감지하고 그에 맞는 컴포넌트와 css가 적용되도록 구현했다.
- 야영장 정보는 브라우저의 경우 side쪽의 drawer로 모바일의 경우 swipe하여 확장 가능한 컴포넌트로 구현했다.
- swipe는 touchstart,move,end 이벤트를 활용하여 css를 transition하지 않고 margin을 조절하는 형식으로 간단하게 구현했다. (네이버 지도앱이 이런 방식으로 구현돼있었다.)
- 야영장 정보는 비동기 작업으로 처리되기 때문에 react suspense를 활용하여 스켈레톤 UI를 띄웠다.
깃헙 링크
swipe 컴포넌트
swipe touchHandler 함수
drawer 컴포넌트
drawer suspense
검색 기능
- 검색의 경우, 디테일하게 하지는 못했고 filter 메서드로 그냥 가볍게 구현했다.
- 검색은 debounce를 활용해서 100ms 동안 입력이 없을 경우, api 요청이 가도록 했다.
- 검색 결과는 비동기 작업이기 때문에, 검색 결과 로딩창을 react Suspense를 활용해서 구현했다.
깃헙 링크
검색 함수
검색 결과 selector
검색창 컴포넌트
북마크
- 북마크는 localStorage를 사용하여 value를 객체로 관리했다.
- 페이지에서 북마크 클릭 시 로컬 스토리지에 값이 저장되며, 로컬 스토리지의 값이 바뀌면 전역 상태에서 북마크 state도 갱신된다.
깃헙 링크
로컬 스토리지 객체 관리
링크 공유
- 현재 URL를 공유하는 기능이며, window객체의 writeText 메서드를 사용하여 구현했다.
- 모달창을 직접 구현해보면서 모달 창의 동작 방식을 이해할 수 있었다.
깃헙 링크
클립보드 저장 함수
링크 공유 모달 컴포넌트
회고
- 이번 프로젝트는 어떤 부분에서는 자신을 얻기도 했고, 자신을 잃기도 했다.
- 자신을 얻은 부분은 내가 구현하고 싶은 서비스나 기능, 페이지의 모양새가 있다면 그게 무엇이든 어찌저찌 구현할 수 있다는 점이다.
- 자신을 잃은 부분은 '과연 내 코드가 옳은 방식으로 짜여져 있을까?'에 대한 의문이다. 요즘 읽고 있는 포스팅은 주로 클린 코드에 대한 내용인데 클린 코드에 정답은 없겠지만 좋은 코드는 어떤 코드일까 계속해서 고민하게 된다.
- 위 내용의 연장선으로 '과연 나는 내 코드의 동작방식을 정확하게 이해하고 있을까?'라는 의문도 함께 들었다. 물론 javascript에 대한 핵심 개념이라거나 동작 방식에 대해서는 어느정도 학습하고 이해하고 있지만 react로 넘어와서는 react의 핵심 개념(예를 들어, virtual dom이라거나, state가 변경될 때 렌더링되는 동작 방식 등)에 대한 이해가 부족하다는 느낌을 받았다. 당연히 충분히 학습하고 넘어가야 할 부분이다.
- 그래서 당분간은 javascript의 개념을 다시 한 번 살펴보고 주요 라이브러리나 브라우저의 동작 방식에 대해 더 깊게 공부를 해볼 예정이다. 프로젝트의 우선순위는 약간 낮춰야 할 것 같다.
타입스크립트
- 타입스크립트를 계속해서 학습은 했지만 프로젝트에 적용해보진 않았다. 마냥 거리감이 있어서였는데, 이번 프로젝트를 하면서 타입스크립트를 적용해봐도 괜찮을 것 같다는 생각이 들었다.
- 아마 그 거리감은 보통 강의를 듣게 되면, 너무 많은 내용을 한 번에 듣기 때문에 어렵게만 느껴져서인 것 같은데 다음 프로젝트는 간단하게 인터페이스 위주로 적용해볼까 한다. 차근차근 타입의 결합이라거나 다양한 자료형의 적용을 시도해보고자 한다.
다음에는
- javascript 프로젝트를 해보고 싶다. javascript로 직접 react를 만들어보고 싶다.(비슷하게 라도)
- 기필코 성능 측정하리라. 성능을 측정해야 내가 뭘 어떻게 개선했는지 눈에 보일 것 같다. 성능 측정에 대한 강의를 들어놔야겠다.
- 기필코 배포하리라. 이번 프로젝트에는 백엔드 개발자 분이 api를 하나만 만들어놓고 탈주를 해서... 배포까진 가지 못했지만 다음 프로젝트는 서버리스로 프론트엔드에서 배포까지 해버리던지 아니면 끝까지 책임지고 할 수 있는 백엔드 팀원을 모집하던지 해서 세상에 내놓고 싶다.
프론트엔드 개발자