RSC 관련 번역 작업 중에 깃헙 Discussions에 Vote 기능의 UX가 재밌어서 긁어와봤다.
과거 커뮤니티 사이트를 만들거나 클론코딩을 진행하면서 좋아요 기능을 구현하는 경우가 종종 있었다.
좋아요 기능을 구현하는 일반적인 플로우는 다음과 같이 이루어 진다.
유저가 좋아요 버튼을 누름
->유저 정보 + 게시물 정보를 담아 서버에 좋아요 API 요청
->서버에서 반영 되었다는 응답이 오면 클라이언트에서 좋아요 카운트 수 +1
(보통 리액트를 사용한다면 state로 저장해서 쓰곤 함)
이 플로우는 전혀 문제가 없는 것 처럼 보이지만, 서버에 문제가 생겨 요청에 대한 지연 시간이 증가하게 되면, 유저는 좋아요 버튼을 누르고도 카운트 수가 업데이트 되지 않기 때문에, 내가 잘 누른게 맞는지 의문을 품으며 다시 누르거나 사이트가 좀 이상한데? 하며 아쉬움을 표할 수 있게 된다.
즉 UX의 저하가 발생할 수 있는데, 이때 사용할 수 있는 방법이 optimistic updates 이다.
플로우는 다음과 같이 진행 된다.
유저가 좋아요 버튼을 누름
->유저 정보 + 게시물 정보를 담아 서버에 좋아요 API 요청
->동시에 클라이언트에서 좋아요 카운트 수 +1
->서버에서 정상적으로 응답이 온 경우라면 아무런 작업을 할 필요가 없고, 에러가 발생한 경우라면 이전 값으로 돌려주는 작업을 진행 해야 함
서버에 요청을 보냄과 동시에, 당연히 잘 응답이 오겠지? 라는 낙천적인(optimistic) 관점으로 데이터를 처리하는 방식이라고 생각하면 된다.
이 방식을 사용하면 유저는 좋아요 버튼을 누름과 동시에 좋아요 수가 올라가거나 내려가는 변화를 볼 수 있기 때문에 실시간으로 처리 되는 느낌이 들어 쾌적하게 사이트를 이용할 수 있게 된다.
이 방식은 꽤나 유명해서 React-Query 같은 라이브러리에서도 어떻게 할 수 있는지 방법에 대해 알려주고 있다.
대부분의 경우 optimistic updates는 에러 처리를 어떻게 하면 좋을지가 문제인데, 이 방법을 깃헙에서 꽤나 재밌게 풀어냈다고 생각하여 글을 작성하게 되었다.
썸네일이나 위에 사진을 보면 알겠지만, 유저가 누르면서 숫자가 증가하며 변하지만, 뭔가 조건이 맞지 않아 투표할 수 없는 상황이라면 다시 원래 숫자로 변하는 애니메이션을 적절하게 배치하여 재밌게 풀어낸 느낌이고, 꽤나 인상적이고 나중에 프로젝트에 녹여내보기 위해 아카이브의 목적으로 적어보았다.
직접 구현해보진 않았지만, 전체 컨테이너 안에 숫자를 담을 수 있는 2개의 서브 컨테이너를 만들어서 좋아요를 누르면 두 컨테이너의 위치를 위로 올리다가, 에러가 발생하면 다시 원상복구 시키는 식으로 구현하면 되지 않을까 생각하고 있다.