프론트엔드 개발 포트폴리오 | 모각코 매칭 서비스
내일배움캠프 4기 웹 개발 과정 React 트랙 수료생 최종 프로젝트 '모코'를 소개합니다.
Sep 04, 2023
모각코(모여서 각자 코딩하자!) 위한 매칭 서비스 “MOCO”
MOCO(모코)는 개발자 문화 중 하나인 모각코 모임을 찾아 코딩 메이트를 매칭해주는 플랫폼입니다.
서비스 둘러보기 (링크)
Github Repasitory (링크)
🛠️ 아키텍쳐
🛠️ 주요 기술 및 기술적 의사 결정
React Query
도입 배경
- 처음에는 파이어베이스 내장 API를 사용했지만, 페이지와 컴포넌트가 여러 갈래로 나눠짐에 따라 서버에 불필요한 데이터 요청이 잦아짐. 이를 한 번에 해결할 수 있는 기술이 필요해짐.
기술 선정 과정
- Redux 상태를 전역으로 사용할 수 있지만 보일러 플레이트 코드가 길고 핵심 데이터를 서버에 요청해서 사용해야만 하는 구조였기 때문에 보다 더 간편한 것을 원했음으로 패스함.
- React Query 1) 핵심 데이터가 서버에 있다는 점 2) 비동기 통신에 특화되어 예외 처리가 쉽다는 점 3) 캐싱 기능을 이용해 데이터 요청을 최소화할 수 있으며 전역 상태 관리가 필요하지 않게 된다는 점 4)Fresh한 데이터가 필요할 때도 옵션을 사용해 새로고침이 없이 데이터를 최신화 할 수 있다는 점 위 4가지 이유로 리액트 쿼리를 도입했음. 리액트 쿼리 도입 결과, useQuery 커스텀훅 + 캐싱 기능으로 props 드릴링과 과도한 데이터 요청을 해결할 수 있었음
Recoil
도입 배경
- React Query를 사용했지만 기능이 늘어나다보니 겹쳐지는 DB정보들을 좀 더 쉽고 간단명료하게 정리해야 할 필요성(리팩토링)을 느낌.
기술 선정 과정
- Redux 상태를 전역으로 사용할 수 있지만 보일러 플레이트 코드가 길고 핵심 데이터를 서버에 요청해서 사용해야만 하는 구조였기 때문에 보다 더 간편한 것을 원했으며 시간 관계상 빠르게 정리할 수 있는 상태 관리 라이브러리를 찾아야 했으므로 패스함
- Recoil 현재 사용하고 있는 Hooks들을 보다 쉽고 안정적이면서 남아있는 시간 내에 빠르게 습득할 수 있는 Recoil이 현 상황에서는 가장 이상적인 상태관리 라이브러리라고 판단하여 적용
Antd Design
도입 배경
- 프로젝트 초반에 프로젝트 기획 및 디자인 최종 결정이 미뤄짐에 따라 빠르게 UI를 구현할 수 있는 수단이 필요했음.
기술 선정 과정
- UI 라이브러리 선택 기준 1. 빠른 개발 속도를 위해 사용법이 아주 간단할 것 2. 기본으로 제공하는 컴포넌트 구조가 단순할 것 3. 최종 디자인이 나오면 커스텀할 수 있어야 하기 때문에 기본으로 제공하는 디자인이 튀지 않을 것
- Ant Desgin 선택 mui도 고려했지만 작업 시간을 단축시키는 것이 목적이었기 때문에 mui보다 사용법이 간단하고 레이아웃을 제공해주는 Ant Desgin을 선택했음. 사용 결과, 빠르게 기초적인 컴포넌트들을 만들 수 있었고 기능 개발을 시작할 수 있었다.
Quill
도입 배경
- 사용자들이 댓글보다는 비교적 긴 텍스트를 작성할 것으로 예상했고, textarea를 사용할 때보다 텍스트 작성 경험을 좋게 만들어줄 기술이 필요했음.
기술선정 과정
- 에디터 라이브러리 선정 기준 1. 추가로 설정할 것이 적은 것 2. 한글지원이 잘 되는 것 3. 위지윅 기능을 지원하는 것 4. 안정적인 것
- Quill 선택 Toast Ui Editor와 Quill 사이에서 고민을 했음. Toast Ui Editor는 NHN에서 만들었기 때문에 한글 입력이 안정적이고 ui도 예뻤음. 하지만 NPM Trend로 확인해봤을 때 Quill이 압도적으로 많이 사용되었기 때문에 안정성이 보장되었고 레퍼런스 자료가 많을 것으로 판단해 Quill을 선택했음. Quill은 선정 기준 4가지에 다 부합했고 도입 결과, Quill을 사용해 줄바꿈 처리나 텍스트 스타일링에 고민하지 않고 원하는 결과를 얻을 수 있었음.
🚀 트러블 슈팅
글 작성시 더블클릭 방지
문제현상
write 페이지에서 ‘작성 완료’ 버튼을 여러 번 클릭하면 클릭한 횟수대로 게시글이 게시되었다.
문제원인
버튼이 클릭될 때마다 글이 작성되는 이벤트가 발생하기 때문
해결방법
react 에서 lodash를 사용할 때 유의할 점
- lodash 라이브러리의 debounce 사용
- 리렌더링 되는 컴포넌트 내에 debounce를 정의한 함수가 있고, 해당 컴포넌트가 state에 따라 리렌더링이 된다면 debounce 함수도 재생성되면서 debounce가 초기화
- 이 버그를 방지하기 위해서는 useCallback을 사용함 useCallback을 이용하여 state가 바뀜에도 debounce함수는 재생성이 되지 않도록 하여 debounce가 초기화 되지 않도록 막음
- 실제 debounce 를 사용할 때에도 debounce 내로 값이 들어가면 초기화 시켜 빈 값이 메모제이션 되는 경우가 발생함
- hadleSubmit 함수의 디펜던시 배열에 맨 마지막에 들어가는 값인 partyDesc 을 넣어 해결
Before & After
Before
문제 현상 gif 확인
After
참고사항
- react 에서 lodash를 사용할 때 유의할 점에 대해 알려준 블로그 : https://kyounghwan01.github.io/blog/React/debounce/#debounce란
- 더블클릭을 막기 위해 디바운싱을 사용해야 한다는 발상 : https://sandny.com/2021/02/16/usidebounce-with-react-hooks/
북마크 업데이트 속도 개선
문제 현상
북마크 버튼을 클릭했을 때 그 반응 속도가 늦어져서 서비스 자체가 느리다는 인상을 줌
문제 원인
JS 내 prefomance API를 사용해서 확인해본 결과,
- 북마크 업데이트 요청에 대한 응답이 오고 난 뒤에야 UI가 변경되고 있음
- 북마크 업데이트 응답 속도는 약 180ms이었고 늦는 경우 200ms였음
유저 입장에서는 북마크 버튼을 클릭하고 나서 늦으면 0.2초 후에 반응하는 UI를 경험해야 했음.
해결 방법
velog 등 다른 웹에서 북마크 버튼을 클릭하고 반응 속도를 측정해보니
빠르면 80ms 늦어도 100ms로 속도감이 좋았음.
현재 북마크 응답 속도가 180 ~ 200ms 사이기 때문에 다른 웹에서 만큼
빠르게 반응하기 위한 방법으로 낙관적 업데이트를 선택했음.
파이어베이스 속도를 높이는 것보다 쉽고 더 효과적인 방법이라고 판단했음.
마침 프로젝트에서 React-Query를 사용하고 있었기 때문에
queryClient.setQueryData를 이용해
기존 데이터에서 해당 게시물의 북마크값만 1씩 증감해주도록 했음.
위 코드가 북마크 업데이트 함수가 끝나기 전에 먼저 실행될 수 있도록 해
북마크 업데이트 요청이 완료되기 전에 UI단에서 변경된 북마크 값을 렌더링할 수 있었음.
Before & After
결과 : 체감 속도 약 2배 감소 (기존 180~200ms에서 80~100ms로) (Optimistic Update : 유저가 보는 화면에서 UI가 변경되는 속도) (Server Update : 실제로 요청이 완료되는 속도)
비교 영상 (좌 : before / 우 : after)
코드
기존 코드
추가 코드
북마크 더블클릭 시 숫자 증감 이슈
🧑💻 👩💻 팀원소개
Share article
Subscribe to our newsletter