React Query와 함께 Concurrent UI Pattern 사용해보기 🐥

계기

내가 생각하기에 프론트엔드 개발을 하면서 가장 중요하다고 생각한 것은 사용자 경험과 성능 개선이었다.

내가 프론트엔드 개발자가 되어야겠다고 생각한 이유도 사용자 경험을 고민하고 개선하는데 흥미를 느꼈기 때문이다.
그래서 나도 웹이나 앱을 사용할 때 그런 경험들에 대해 관심있게 보게되는거 같다.

내가 생각하기에 사용자 경험에 성능이 빠른것도 당연히 좋지만 적절한 ⭐️로딩화면과 에러화면⭐️을 보여주는것도 매우 중요하다고 생각하였다.
그래서 이번 init 프로젝트에서는 api 요청만 하는것에서 끝나는것이 아닌 로딩화면과 에러화면을 적절히 잘 처리하는 프로젝트를 해봐야겠다고 생각했다.

그러던 도중에 react-query에 대해 알게되었고, 또 마침 카카오페이 테크 블로그에 작성된 React Query와 함께 Concurrent UI Pattern을 도입하는 방법 이 글을 보게 되었다.

글을 읽어보니

사용자 경험을 개선하기 위함과 Suspense와 ErrorBoundary를 사용하면 (선언적으로 UI를 구성할 경우) 컴포넌트들의 관심을 확실하게 분리할 수 있고, 이를 통해 유지보수가 편리한 프로젝트 환경을 유지할 수 있으며 사용자 경험 향상을 위한 다양한 UI 요소를 활용할 수 있다는 이 점도 있기 때문에 react-query와 함께 Cocurrent UI Pattern을 사용하기로 결정했다!

로딩화면

init 프로젝트의 메인 화면이다.

메인화면은 크게 3가지 부분으로 구성되어있는데 banner 영역(이미지), 최신 Q&A , aside (인기태그 리스트) 부분이다.

메인화면의 로딩이 전체화면을 덮는 로딩이 아닌 부분적인 로딩화면을 적용하였다.

1. banner의 이미지 부분은 이미지 로드가 다 되기전까지 블러처리된 이미지가 화면에 보이도록 하였다.
2. 최신 Q&A 부분은 최신 Q&A가 불러오기 전까지 적절한 로딩 화면을 보여준다.
3. Aside 부분은 인기 태그 리스트를 불러오기 전까지 적절한 로딩 화면을 보여준다.

적용을 해보니 훨씬 사용자 경험을 좋아짐을 느낄수 있었고, 느린 네트워크로 테스트를 해본결과 효과는 더 컸다.
사실 사용자들이 항상 빠른 네트워크, 성능이 좋은 기기에서만 접속을 하는것이 아니기에 아무리 빠르게 로드되어보인다고 하더라도 로딩화면은 필수라고 생각한다.

로딩 화면(스켈레톤)을 하였으면 이제 끝일까? 아니다 !
이제 에러 화면이다. 😭

에러화면

에러 처리도 로딩화면 만큼이나, 아니 오히려 더 중요하다고 생각한다.

에러 처리는 세가지로 나누었는데,
1. useQuery(데이터를 불러올 때) 사용시에는 아래와 같이 보여주었다.
에러가 생기면 전체 페이지를 감싸는 것이 아닌 특정 부분만 에러 처리를 하였다.

2. useMutaion 사용시에는 1번처럼 보여주면 안되기 때문에 아래 화면과 같이 토스트 메시지로 해당 에러 메시지를 보여주었다.

3. 전체 화면을 덮는 에러인 404에러와 500에러
또한 404에러와 500에러의 경우 다르게 보여주었는데,
404는 page not found로 버튼을 누르면 메인화면으로 돌아가도록했고,

500은 리액트 쿼리에서

useErrorBoundary: (error: CustomError) => error.statusCode >= 500,

이런식으로 코드를 작성 해줌으로써 500에러이면 에러바운더리를 사용해 전체화면을 덮도록 하였다.

그동안의 프로젝트에서는 에러처리를 console.log에 에러를 찍거나 에러가 발생했어요(모호한 이유 설명)등으로 에러처리가 끝나는것이 다였는데, 경우에 따라 (나의 경우는 3가지) 에러 화면을 보여줌으로써 사용자 경험이 좋아짐을 느꼈다.

사용해 본 나는 무엇을 느꼈을까?

로딩화면, 에러화면은 중요하다고 생각은 계속 해왔지만 단순히 기능개발만 주로 해왔던거 같았다. 사실 빠른 네트워크를 사용하며 성능이 좋은 기기를 가지고 있고 에러는 발생하지 않는다면 좋겠지만 사실 다양한 사용자들이 있기 때문에 이런 측면들도 고민이 해야한다고 생각했다. 이번에 로딩화면과 에러화면을 구현해보면서 좀 더 사용자 경험을 생각하는 프론트엔드 개발자가 된 느낌이라 뿌듯했다 😭😭 사실 에러화면을 경우에 따라 어떻게 보여줄지 고민을 많이 했고, 어려움이 있었다. 구현의 어려움보다는 내가 3가지 경우로 나누어서 에러 처리를 했는데, 케이스마다 어떻게 에러처리를 할지에 대한 고민이었다. 고민을 많이 한만큼 그 결과는 나름 만족이다.!
사용자 경험 개선을 위해 해보고 싶은것들이 몇 가지 더 있는데 차근차근 적용해보려고 한다.! 😎