Closed jagaldol closed 1 year ago
쪽지 api 구현에 있어 와이어프레임 기획 상 모호한 부분이 존재했습니다.
대화방(쪽지) 목록 조회(/api/messages/opponents) 의 경우, countNew와 countAll을 응답에 포함되어 집니다.
/api/messages/opponents
저희 UI는 채팅에 가까운 UI로 countAll에 받았던 모든 쪽지의 개수를 넣으면 이상할 수 있습니다.
카카오톡으로 생각했을 때 전체 대화방을 통틀어서 받은 메시지 수가 채팅방 목록에 적혀 있으면 이상할 것입니다.
따라서 와이어프레임 상의 기획에서 부터 논의가 필요할 것 같습니다.
또한, 특정 유저와의 쪽지를 클릭하면 채팅 UI로 쪽지 받고 보내는 창으로 넘어갑니다.
현재 구현은 default size 20으로 최신 쪽지들(상대가 보낸거 내가 보낸거 포함 20개)을 돌려줍니다. 그리고 이전 쪽지에 접근하기 위해서 위로 스크롤해 위에 닿으면 20개가 다시 요청됩니다.
문제가 될 상황을 가정하겠습니다.
자신이 본 20개가 새로운 쪽지인줄 알고 30개를 무시하는 경우가 발생 가능합니다.
카카오톡을 다시 생각해보면 안 읽은 메시지가 존재하는 채팅방의 경우 안읽은 메시지 위치부터 로딩됩니다. 이전 대화도 일부 포함하고요.
이런 부분을 생각하면 api 동작 방식이나 구조에 대한 고민이 필요할 것 같습니다.
쪽지 목록 조회에서 각 쪽지방에 대한 새로운 쪽지 개수 주는 걸로 해결하기로 의견 나왔습니다.
countAll과 countNew는 삭제합니다.
Description
쪽지 api 구현에 있어 와이어프레임 기획 상 모호한 부분이 존재했습니다.
대화방(쪽지) 목록 조회(
/api/messages/opponents
) 의 경우, countNew와 countAll을 응답에 포함되어 집니다.저희 UI는 채팅에 가까운 UI로 countAll에 받았던 모든 쪽지의 개수를 넣으면 이상할 수 있습니다.
따라서 와이어프레임 상의 기획에서 부터 논의가 필요할 것 같습니다.
또한, 특정 유저와의 쪽지를 클릭하면 채팅 UI로 쪽지 받고 보내는 창으로 넘어갑니다.
현재 구현은 default size 20으로 최신 쪽지들(상대가 보낸거 내가 보낸거 포함 20개)을 돌려줍니다. 그리고 이전 쪽지에 접근하기 위해서 위로 스크롤해 위에 닿으면 20개가 다시 요청됩니다.
문제가 될 상황을 가정하겠습니다.
자신이 본 20개가 새로운 쪽지인줄 알고 30개를 무시하는 경우가 발생 가능합니다.
이런 부분을 생각하면 api 동작 방식이나 구조에 대한 고민이 필요할 것 같습니다.