[Dev-Log] 2021.11.04

### **오늘은 어떻게 프로젝트에 기여했나요?**
- 지도 조회와 함께 또 다른 핵심 기능인 채팅 기능을 완성하였다. 백엔드 팀원 분이 socket.io에 대한 다른 팀원들의 이해를 돕고자 미리 더 많이 학습해두었고, 실습한 결과를 토대로 잘 설명해 주었다. 기본 코드를 참고하여 적용하였고, 팀원 분에게 물어봐 가며 오류를 해결할 수 있었다.
이 기능을 활용하는 ChatBox 컴포넌트가 Chat 페이지 상 에서 '나의 약속 카드 목록'( Component) 와 '맞밥 메이트 보기'( Component)

### **오늘의 프로젝트에서 힘든 점은 무엇인가요?**
- 상태관리를 처음부터 Redux 및 Context API + useContext 로 하지 않아서, 현재 로그인 여부 state와 userInfo 등의 기본 상태정보만 리덕스로 관리하고 있다. 그리고 컴포넌트 재사용성과, CSS를 위한 구조를 위해 여러 겹의 컴포넌트로 구성되게 되었고, (List>CardList>Card 이 구조를 Main 페이지와 Chat 페이지에서 활용한다.) 따라서 props drilling이 만연하게 되었고, 보다 불필요하게 삼항연산자로 렌더하는 등 아직 조악한 코드를 짜는 것 같다. 이 부분은 꼭 리팩토링을 해볼 것이다.
- 프론트 팀원 개인으로서 내 자신의 경향을 하나 알게되었다. 서비스 및 기능에 필요한 서버 로직을 백엔드 팀원과 논의하며 백엔드에서 작성하였기 때문에, db나 서버 로직을 더 수정하지 않는 방향으로 작업해보려 했다. 여러번 논의하고 수정하며 최선으로 구현해 둔 것이라 생각하기도 하고, 프론트엔드 개발자 신입으로서 해결해보는 연습이라고도 생각했다. 그런데 좀 더 생각해보면 서비스를 만드는 것, 작업은 팀의 협업이므로 더 좋은 방향이 있을 것이라 생각해야 할 것이다. 나는 first project 때 백엔드 파트를 담당하여 작업해 보았다. 프론트 뿐만이 아니라 백을 잘 알아야 클라이언트-서버 간 요청응답이 오가는 로직 즉 기능에 대해 이해도가 높아지고, 보다 효율적이거나 좋은 코드이거나 하는 방향으로 구현할 수 있을 것이라 생각이 든다. 그러므로 서버 로직, db 관점에서도 코드 로직, 기능 구현, 메모리 등등을 고려하는 시각을 넓혀야 겠다고 생각한다.
- (이 사항은 예를 들어 현재 userInfo 데이터에는 음식취향 taste 자체 필드는 없고, 테이블매너인 etiquette 필드는 있는(배열) 것과 관련되어 있다.
- 개별 테이블 taste에서 조인하고 있으며, 이 taste 값을 유저들의 음식취향 top list등으로 활용해볼 수 있을 것 같아 만들어 둔 것이기도 하다.
- etiquette의 경우 기본 사항으로 제시할 것이 많지 않고, 사용자가 커스텀하여 추가할 수 있도록 하므로 따로 테이블을 만들지 않았다. 다만 이러한 경우 taste와 etiquette 또한 Redux로 관리해도 될 것 같다는 생각이다.
- 그리고 selected (선택 여부)프로퍼티를 boolean 값과 함께 initial state 로 관리하는 방법도 고민해야할 것이다.(아직 헷갈린다)

### **내일은 프로젝트에 기여하기 위해 무엇을 해야 하나요?**

- [x] MateList 컴포넌트 구현
- [x] card 조회(card_id 쿼리) 요청 작성 - 다른 참여자 user_id 가져와 정보 렌더하기
- [x] chat 페이지에서 main 으로 이동(nav바) 시 error 핸들링
- [x] Main css 수정(datepicker css 중첩, background-color
- [x] 지역, 구, 음식점, 날짜 등 옵션 값 선택 후 '약속 만들기' 버튼 클릭 시 그 페이지로 해당 값 내려주기
- [x] 반응형 CSS
- [x] 모달 끄기
- [x] 채팅 알림 기능
- [x] 클라이언트 배포 업데이트