어제보다 더 나은 오늘

이번주에 버그로 등록된 이슈 하나를 해결했던 과정이 재미있어서 기록으로 남겨두는 게 좋겠다는 생각이 들었다. 먼저 제보된 이슈는 다음과 같았다.특정 문서를 업로드했을 때 편집 화면에서 스크롤 이동이 되지 않고, A 기능이 동작하지 않음  A 기능은 편집 화면 내에서 스크롤 이동시 뷰포트에 들어와 있는 아이템을 대상으로 서버에 배치로 요청을 한 다음, 해당 응답 결과를 가지고 화면에 특정 UI로 렌더링하는 기능이었기 때문에 이건 스크롤 이슈였다.  먼저 해당 현상을 재연하기 위해 버그가 발생한다고 제보한 계정으로 접속해 해당 문서를 확인해 보았다. 그런데 내 컴퓨터에서는 스크롤도, A 기능도 정상적으로 동작했다. 내 컴퓨터는 맥북이었고, 버그를 제보한 분의 컴퓨터는 윈도우 데스크탑이었다. 그래서 팀 공용 ..

앞의 포스팅에서 언급했던 것처럼 무한스크롤 관련 이슈를 해결하고 나니 성능 이슈가 부각되었다. 원문과 번역문을 두고 사용자가 편집할 수 있는 서비스인데 아이템이 500개 정도만 되어도 키보드 입력 이벤트가 발생하면 사용자가 키보드를 누르고 화면에 해당 글자가 뜨는 시간 사이에 지연이 체감되는 정도였다.  list virtualization 또는 windowing 기법을 적용해서 뷰포트에 보이는 아이템만 DOM 노드에 가지게 하면 성능 면에서 큰 개선을 할 수 있을 거라고 생각했다. react-virtualized가 대표적인 windowing 라이브러리로 지금은 legacy가 된 이전 버전 react 공식 문서의 성능 최적화 파트에서도 추천하는 라이브러리를 먼저 고려했다.  프로젝트의 요구 사항 중 목록 ..

딱 1년 전 이맘때 부트캠프 파이널 프로젝트를 마친 후 회고를 작성하면서 아쉬운 점으로 "무한스크롤도 써보고 싶었던 ui인데 시간 문제로 도입하지 못했다"고 꼽은 적이 있다. 그리고 그로부터 약 10개월 뒤 무한 스크롤을 원없이 사용하게 된다 😇 지난달 다른 팀원이 맡았던 파트를 인계 받았는데 그 중 메인 feature가 무한 스크롤이었다. 인계 받을 당시 프로젝트의 가장 큰 이슈는 다음과 같았다. 1. 스크롤을 위아래로 이동함에 따라 nextPage와 previousPage를 fetch하고, 서버에서 응답으로 받은 데이터를 UI를 그리는데 사용하는 배열 안에 순서에 맞게 삽입하는 게 때때로 올바르게 동작하지 않고 있었다. 가령 [... 6, 7, 8, ...] 페이지가 렌더링되어야 하는데, [... 7..