ljk1782
commented
8 months ago 초대의 경우에는 약간의 속임수로 '내가 read한 데이터는 아니지만 마치 내가 read한것처럼' 표현되도록 했다.
기본적으로
- 초대한 사람
- 초대받은 사람으로 나뉜다.
초대한 사람을 기준으로는 내 채팅방 목록부분(메신저 메인화면)에서 채팅방 멤버의 개수를 1 증가. 하도록 했고
초대받은 사람을 기준으로는 채팅방 정보를 반환하여 메신저 메인화면(채팅방 목록)을 갱신하도록 했다. 다만 이때 받은 데이터는 초대한 사람을 기준으로 검색한 채팅방 정보이지만 크게 상관없다고 판단했다. 왜냐하면 채팅방에 초대되면 그 이전의 채팅을 굳이 읽었다고 처리하지 않아도 되기 떄문이다.
위처럼 강제구독 처리하는 부분은 이미 열려있는 employeeCode(계정별)에 속임수 채팅방 데이터를 전달하는 것으로 완료했다.
채팅 스크롤 같은 경우 채팅이 갱신되기 전에 아래로 내려가는 이슈가 있었는데 이는 useEffect의 순서를 적절히 바꿔서 해결했다. 또한 맨 아래로 내려가는 버튼을 추가해 그 버튼을 누를 경우에만 맨 아래로 내려갈 수 있게 헀다.
스크롤은 다음과 같은 경우가 있다.
채팅을 치고 값을 받을 경우. 맨 아래로 내려가야 하는데. 받은 채팅이 내꺼인 경우는 확실히 맨 아래로 내려간다.
값을 받았으나, 내꺼가 아닌 경우는 스크롤을 하지 않는다. -> 조금더 응용하면 아래에 무슨 채팅이 있는지 표현하면 될 것이다.
1번과 2번을 정리하면 채팅데이터를 받았을때, 그것이 나 자신의 것이냐 아니면 다른 사람의 것이냐에 따라 다른 코드를 작성하면 될 것이다.
채팅창을 완전 처음 킨 순간. 즉, 초대받고 처음 들어간 경우. 맨 위를 표시하면 되므로 이 경우는 생각할 필요가 없다.
어느정도 채팅이 있는 상황. 즉, 안읽은 채팅이 어느정도 있어서 그 위치부터 읽는게 필요할 경우에는. 전달해주는 DTO에 필드 하나를 추가하도록한다. 채팅을 전달받은 시점에서는 아직 read_status를 작성하지 않았기 떄문.
4번의 경우 backend도 어느정도 건들여야 한다.
초대시 강제 구독 처리는 이전의 것들을 끝내고 작성하는데, 간략하게 얘기해보자면, 채팅방만 구독처리 하는게 아니라. employeeCode. 즉, PK값으로 각 계정은 자기자신만의 endPoint를 구독처리 해놓는다.
저 endPoint는 구독을 요청하는 endPoint로 값을 전달받으면 그것을 적절하게 해석하여 구독하게 한다.
이 작업이 필요한 이유는