대댓글 기능을 구현하는데 중요한 것은 프론트일까 백엔드일까 생각할 수 있었다. 우리가 선택한 방법이 정말 좋은 방법이라고 생각하지 않는다.
댓글 작성
일단 댓글 작성은 기본적인 POST를 통해 구현이 가능하다. 서버에서 필요한 값들을 body 안에 넣어 보내기만 하면 프론트는 땡이라고 할 수 있다.
라고 한다면 말이 안 된다.
일단 댓글을 작성하면 내가 쓴 댓글이 정상적으로 잘 올라간 것인지 유저가 확인할 수 있어야 한다.
프로젝트에서 이 부분을 구현하지 못 했던 것은 post를 보낼 때, commentId 값을 생성할 수 없었기 때문이다.
또한 가장 큰 이유는 리액트 쿼리를 이용해서 데이터 패치를 하기 때문에 나중에 받은 값이 가장 위로 보이게 하는 것에 제약이 있었다.
이런 부분은 리패치가 일어나기 전 setQueryData를 이용해서 임의로 먼저 보이게 코드를 짤 수 있지만, 역시 commentId가 없어 구현이 어려웠다.
당시 왜 commentId를 post의 res값으로 받지 않았던 것인지... 나는 왜 미련 했던 것인지..
댓글을 구현하면서 소통의 중요성을 다시금 깨달았다.
하지만 post의 res 값으로 id값을 받아온다고 해도, 문제가 있다.
리액트 쿼리의 리패치가 일어나서 댓글 데이터가 fetch 되었을 때, 고의적으로 가장 상단에 있는 댓글이 아래에도 나올 확률은 백프로이다.
이는 발상의 전환이 필요하다.
최신 순으로 댓글 정렬하기
댓글을 작성하면 최신 순으로 나오면 어떤가 생각해봤다. 이는 글을 읽는 흐름을 고려하지 않은 느낌이 든다. 댓글은 짧은 덕담으로 끝날 수 있지만, 유저간 소통을 할 수 있는 수단 중에 하나이다. 그렇기에 댓글을 통해 나눈 대화 흐름을 쉽게 파악할 수 있게 구성해야 한다.
때문에 댓글은 아래로 내려가는 구조가 더 맞다고 생각한다.
댓글 작성 후 가장 아래로 내리기
댓글을 작성하고 자동적으로 내가 쓴 글 쪽으로 스크롤을 옮기는 방법도 있는 것 같다. 지금 내가 쓰고 있는 벨로그는 이런 방식을 사용하고 있다. 하지만..! 어딘가 모르게 불편하다. 구체적인 이유를 진단할 수 없지만, 갑자기 훅 내려가는 것이 어딘가 불편한 느낌을 받는다.
역시 유튜브...?
역시 유튜브는 대단한 기술을 적용했나보다
리펙토링을 시도해보자ㅠ
대댓글
대댓글 기능은 굉장히 까다롭다. 프로젝트에서 구현한 것은 1 depth의 대댓글만 지원을 하기 때문에 대댓글에 대댓글을 달 수 없다.
이렇게 구현한 이유는 딱 한 가지이다. 어렵기 때문이다. 마지막 3주차에 어려운 기능을 구현 하려다 보니, 그 중에서 쉬운 방법을 선택했다.
대댓글을 무한으로 달 수 있는 것도 사용자 관점에서 문제가 분명히 있다. UI적으로 계속 들여쓰기가 되면 마치 피라미드를 구경할 수 있을 것 같은 느낌이 든다.
적당한 depth를 정해서 구현을 해야하는데, 해당 depth를 어떻게 정할 수 있을지도 고민을 해봐야 한다.
일단 우리는 Comment 스키마에 parentId를 통해 대댓글인지 아닌지를 확인 한다.
parentId가 있을 경우 댓글 get요청을 받았을 때 commentId가 parentId인 경우에 childComment 배열에 담겨 프론트로 데이터가 넘어오게 된다.
이렇게 구현을 했기에 one depth 댓글만 가능한 것이다.
결론
기술적인 문제가 있어 깊은 대댓글을 구현하지 않았지만 대댓글을 깊게 팔 수 있다면 사실 댓글이 아니라 채팅이 더 좋은 방법일 것이다. 나름 이유가 있는 코드 구조였다..!
