Dani's Dev TokTok

들어가며 리팩토링 하기 전의 채팅방 기능에는 누군가가 모임에 들어갔을 때, 즉 채팅방에 입장했을 때 입장했다는 메시지가 없었다.이런식으로 누군가가 들어왔음에도 어떤 사람이 입장했는 지에 대한 메시지가 없었다.사용자 경험을 개선하기 위해 입/퇴장 메시지를 표시하는 것으로 리팩토링을 했다. 리팩토링 과정 이 프로젝트에서는 특정 모임을 생성하면 그 모임에 대한 채팅방이 열리고,누군가가 모임을 가입했을 때 채팅방에 입장하는 구조였다. 그러므로 입/퇴장 메시지를 받기 위해서는 누군가가 모임을 가입/탈퇴 했다는 정보가 필요했다.즉, 사용자가 보내는 메시지가 아니라 일종의 시스템? 메시지를 받아 올 수 있도록 서버에서부터 코드를 고쳐야 했다.담당 백엔드 분과 대화해서 그렇게 할 수 있도록 서버 쪽 코드를 고쳤다. 고..

1. 문제 발생기존에 특정 채팅방에 접속했을 때, 소켓이 열리도록 한 로직을접속해있지 않은 채팅방의 메시지도 실시간으로 업데이트 하기 위해 웹소켓을 여는 로직을 커스텀 훅으로 만들어서채팅 목록 페이지에 접근했을 때 소켓이 열리도록 로직을 수정했다.그 과정에서 특정 채팅방(A) 를 나가서 다른 채팅방 (B)를 옮겨갔음에도 B 채팅방에 보낸 메시지가 A 채팅방에도 전달되는 버그가 있었다.2. 원인 추론위에서 언급했다시피 기존에 특정 채팅방에 접속해야 열리는 소켓을 커스텀 훅으로 만들어서 따로 파일을 만들었다. 아래는 변경하기 전 코드의 일부다.onConnect 내의 로직을 변경했다. 기존에는 특정 채팅방에 대한 구독만 했기 때문에 그냥 chatroomId을 redux 의 state에서 받아왔다.  cons..

이전에 했던 하이볼 레시피 공유 사이트는 node.js 서버와 템플릿 엔진은 ejs 를 사용했다. 실제로 프론트엔드에서 ejs를 쓰기보다는 리액트같은 라이브러리를 많이 사용하기 때문에그것에 맞춰서 리팩토링을 하고자 한다. 이것을 리액트로 할까 vue.js 로 할까 고민을 많이 했는데SEO 을 고려해서 SSR 을 가능하게 해주고, 요즘 많은 기업에서 요구하고 있는 Next.js 를 사용하기로 했다. 아직 Next.js 에 대해서 자세히 배우지는 않아서 일단 배운 다음에 천천히 적용시켜볼 예정이다!

1. 발표 후 받았던 피드백 이번에도 피가 되고 살이 되는 피드백을 받았다.2차 프로젝트를 하면서도 느꼈지만 내 눈에 부족한 부분은 다른 사람 눈에도 그렇게 보인다는 거였다.UI 디테일에서 아쉬움을 표하셨는데, 나도 똑같이 느낀 부분이라 마음이 좋지 않았다.그리고 내가 맡은 부분에서 찝찝함을 느꼈던 부분까지 콕 찝어 주셔서 다시 한 번 반성하게 되었다. 피드백을 받았던 것을 바탕으로 프론트 담당 팀원들과 조금 회의를 했다.전반적으로 디테일을 올리는 방향으로 리팩토링을 하자고 이야기를 했다. 그래도 다른 팀원분들이 응 나 플젝 끝~ 안녕~ 이런 마음이 아니라퀄리티를 끌어올리려고 하는 열정을 보이셔서 참 좋은 팀원들을 만났다 싶었다.  2. 파이널 프로젝트 소감이번에도 3주란 시간동안 프로젝트를 하게 되었는..

1. 문제 발생프로젝트를 배포하고 나서 채팅 테스트를 하는데 실시간 채팅에서서로 동시에 채팅을 하고 있음에도상대방 메시지 수신 시간과 나의 메시지 송신 시간이 일치하지 않은 현상이 있었다.(로컬에서는 생기지 않았던 문제!! ㅠㅠ)분명 RDS 에는 한국 기준 보낸 시간으로 잘 저장이 되는데 수신할때나, DB 에서 불러올 때는 시간이 이상하게 변해있었다. (나중에 알고보니 UTC 시간으로 변환되서 오던 것이었다.) 2. 원인 추론로컬에서는 저 현상이 없었어서 혹시나 rds 에 저장되어 있는 시간이 이상한걸까? 싶어서백엔드 담당분께 rds 에 시간이 어떻게 저장되어 있는지 여쭤봤다 그러나..한국 기준 시간으로 이쁘게 잘 저장되어 있었다.그래서 처음에는 내가 시간 로직을 이상하게 한걸까? 싶어서 로컬에서 엄청 ..

프로젝트 발표 후, 리더님들께 피드백을 받았을 때두 분의 공통된 의견이채팅 목록 페이지의 모바일 UI 가 좋지 않다고 말씀하셨다. 납득이 갔던 것이 나도 UI 를 만들면서 음.. 이거 좀 이상한디? 라고 생각했기 때문이다.두 분의 의견을 받았기 때문에 해당 UI 를 고치기로 했다. 웹뷰에서는 왼쪽에는 내가 참여한 채팅방의 목록, 오른쪽에는 접속해있는 채팅방을 보여주는 것으로 구성했다.이것까지는 나쁘지 않은데 문제는 모바일 UI에서 였다. 기존 모바일 UI 에서는 채팅방 목록을 상단에 빼고, 하단에 접속중인 채팅방으로 구성했다.그리고 참여하고 있는 채팅방 목록이 가로 길이보다 길어지면 터치로 이동할 수 있게 구현했다. 사실 화면을 구현하면서도 찝찝함이 있었는데...너무너무 구리다는 것이었다!하지만 시간에 ..

1. 문제 발생웹소켓을 연결하고 채팅 테스트를 하던 중특정 컴퓨터에서 메시지가 두 번 보내지는 오류가 있었다.그런데 다시 새로고침을 하면 메시지가 한 개로 보였다.DB의 채팅 메시지 테이블에도 메시지는 하나만 저장되어있었다. 2. 원인 추론메시지의 상태를 저장하는 것으로 redux-toolkit 을 사용했다.거기서 메시지를 보내고 받는 것을 setMessages 라는 액션을 이용해서redux 의 messages 라고 지정된 state 에 저장했다.그리고 그 messages 는 메시지를 렌더링 하는 컴포넌트에서 map 메서드를 이용해서출력되도록 구성했다.  return ( { messages?.map((message, index) => ( )) ..

0. 3차 팀 프로젝트가 끝난 후 쓰는 회고록기간 : 2024.10.21 ~ 2024.11.08개발인원 : FE 4명 BE 4명담당 역할 : 프론트엔드주제 : 부모와 아이가 함께할 장소와 모임을 찾는 사이트깃허브 :- frontend code : https://github.com/SeSAC-3rd-Kinderpia/kinderpia_front1. 프로젝트 주제이번 프로젝트는 클라이언트는 React와 TypeScript, 서버는 Spring Boot 를 이용해서 만들었다. 어떤 주제로 할까 다방면으로 고민하면서 공공 데이터 API를 써보자라는 의견이 나왔고, 공공 데이터 포털에서 쓸만한 데이터를 찾다가 어린이 관련 데이터들을 찾았다. 그것들을 어떻게 사용할 수 있을까 고민하다가초등학교 자녀들을 가진 부모들..

이번에 부트캠프에서 하는 프로젝트에서 채팅 기능을 맡았다.프론트엔드는 리액트, 백엔드는 스프링부트를 사용했기 때문에이전에 배웠던 socket.io 가 아니라 stomp 를 사용했다.Stomp 는 Simple Text Oriented Messaging Protocol로 웹소켓을 기반으로 하는 메시지 전송 프로토콜이다.  챗지피티 선생님께선 socket.io 랑 stomp 의 차이를 이렇게 말씀하셨다.  위 부분에 대해서는 웹소켓을 더 자세히 공부해야 잘 이해를 할 것 같다.어쨋든 요약하자면1. 서버가 스프링부트임2. 스프링부트에서는 웹소켓을 사용할 때 stomp 를 많이 사용한다.3. 그래서 클라이언트에서도 그것에 맞춰서 stomp 를 사용했다. 이렇게 되겠다. 리액트에서 stomp 를 이용하려면 당연히 ..

설계부터 배포까지 거의 한달 정도 걸렸던 프로젝트를 마치며 느낀 점을 써보고자 한다. 1. 발표 후 받았던 피드백.. 두 리더님들이 피드백을 엄청 잘해주셨다! 특히 구현하면서 찝찝했던 점을 정확히 지적해주셔서 내 눈에 부족한 부분은 다른 사람의 눈에도 잘 보인다는 것을 다시 한 번 깨달았다. 이 점은 앞으로 더 신경 써야겠다고 느꼈다.제일 뿌듯했던 피드백은 로고가 이쁘다는 거랑.. UI적인 측면에서 잘했다는 칭찬이었다.물론 아쉬운 점도 많이 얘기해주셨지만 긍정적인 피드백이 큰 힘이 되었다.또한, 사이트의 특성을 고려해서 유저가 제일 많이 접속할 것 같은 디바이스 중심으로 프로젝트 화면을 설계해야 한다는 피드백도 들었다.나는 사실 휴대폰이 작아서(아이폰 se2ㅋㅋ) 휴대폰으로는 쇼핑을 잘 안하는데요즘은 대..