MasonTALK 개인 프로젝트 1일차(2023.04.26.)

💬 프로젝트 주제

유저들과 일대일 채팅이 가능한 미니 서비스를 구현할 예정입니다.

여자친구와 둘만 이용하는 채팅 애플리케이션이 있으면 좋겠다는 대화를 나눈 후에 계획했습니다.

🎨 기술 스택

• 프론트엔드 - react, react-bootstrap, react-router-dom
• 백엔드 - express, mongoose, postman
• 기타 - socket.io

채팅이라는 핵심 기능 구현에 집중하기 위해(=스타일링에 대한 고민을 최소화하기 위해) 리액트 부트스트랩을 사용했습니다.

클라이언트 뿐만 아니라 서버에 관한 로직에 대해서도 차근차근 생각해보면 서비스가 동작하는 전체적인 workflow를 이해할 수 있겠다는 기대감이 있었습니다.

이에 express로 서버를, mongoose로 데이터베이스를 구축했습니다.

마지막으로 서버 driven 이벤트를 발생시키기 위해 socket.io를 사용했습니다.

🕹 1일차 구현 사항

프론트엔드

1. React Context API를 사용한 회원가입
2. 로컬스토리지를 활용한 유저 로그인 여부에 따른 protected routes 설정

백엔드

1. 유저 관리를 위한 MVC 패턴 작성: 유저 스키마, 라우트 경로, 컨트롤러(핵심 함수)

🚀 트러블슈팅

1. Maximum update depth 이슈

Warning: Maximum depth exceeded. This can happen when a competent calls setState inside useEffect, but useEffect either doesn't have a dependency array, or one of the dependencies changes on every render.

• WHAT? 무한루프에 갇힌 업데이트 횟수
• HOW? 올바른 경로 설정 (/login → /signin)

사전에 정의하지 않은 경로를 Link 태그에 등록해서 발생한 마이너한 문제였습니다.

하지만 오히려 문제 해결을 위해 고민하면서 useEffect 훅의 동작 방식에 대해 디테일하게 생각해보는 기회였습니다.

그 과정에서 useCallback 훅을 적용해 렌더링 성능 개선에 대해 고민해보는 시간 또한 가질 수 있었습니다.

2. 회원가입 로직 구현 방식

• WHAT? 컨텍스트 정보 관리 방식
• HOW? 유저 정보 관련 로직은 모두 컨텍스트 내부로 이동

리액트 Context API를 사용하여 AuthContext를 생성하면서 한 가지 의문이 들었습니다.

"회원가입 시 기입하는 정보(name, email, password 등)는 컨텍스트 내부에서 관리해야 할까? 아니면 회원가입 페이지에서 별도로 관리해야 할까?"

 

처음에는 회원가입 정보는 전역에서 사용하지 않기 때문에 회원가입 페이지 내부에서만 관리해도 되겠다고 생각했습니다.

하지만 어느 순간 갑자기 유저 관련 정보가 분산된다는 생각이 들었습니다.

이에 생각을 달리 시도했습니다.

"회원가입 정보도 유저 관련 정보이기 때문에 유저 컨텍스트에서 관리하는 편이 깔끔하겠다."

약간의 코드 수정 과정을 거친 결과, 관련 에러가 발생할 때 컨텍스트 코드만 들여다보면 됐기 때문에 코드의 유지보수성이 향상되는 효과가 있었습니다.

잊지 않겠습니다. 클린 코드!