[view] 대규모 레포지토리 대응을 위한 데이터 로딩, 리스트 렌더링 최적화 관련 논의

[seungineer]

8월 8일 View 성능 최적화팀 논의 내용과 더불어 렌더링 최적화 관련 의견 여쭙습니다!

Related Issues

#626 #601 #421

현 상황

• 대규모 레포지토리의 긴 초기 로딩 시간
  • 레포지토리에 대한 모든 정보를 한 번에 불러와 한 번에 가공하기에 engine에서 view로 데이터를 send 하는 데까지 오랜 시간이 걸리고 있습니다.

2024-08-09.10.01.43.mov

• 대규모 레포지토리(10,000 Commit 이상) Open 시 사용이 불가능할 정도로 버벅임
  • 레포지토리의 CSM Node가 패널에 전부 load 되어 DOM 내 Element가 매우 많습니다.
• 불필요한 렌더링 발생
  • 한 컴포넌트가 렌더링될 때, Context API에 의해 패널 대부분의 컴포넌트가 재렌더링 됩니다([view] 성능 측정 결과 관련 논의 - 2 #619).

진행 예정

대규모 레포지토리 대응

• 로딩 시간 단축

  • Engine 팀과 협의하여 초기 모든 정보를 받아올 필요가 없도록 수정 예정입니다([engine] 성능 최적화를 위한 view와의 메시징 방안 (무한 스크롤 X git log 분할 처리) #618).
  • CSM Node 리스트가 보이는 view에서 일정 영역 하단까지 스크롤 했을 때 Engine으로부터 추가적인 데이터를 받아 렌더링 하는 방식이 적합할 것으로 판단하였습니다.
  • CLOC, COMMIT # 정보를 보여주는 Temporal filter 부분은 Engine으로부터 별도 message를 받아 처리하여 초기 로딩 직후에도 전체 overview를 볼 수 있게 하고자 합니다.
    • 아직 불러오지 않은 데이터를 Brushing 하여 조회하고자 할 때는 어떻게 처리할 수 있을지 고민 중입니다(UX로 Brushing이 불가능하게 혹은 필요한 부분을 Engine에 즉시 요청 등) 🤔.
    • 위 방식에 대해서도 경험해 보신 분들의 의견을 여쭙습니다. 🙌

• 대규모 레포지토리 Open 시 렌더링 최적화 방안

  
  • DOM 내 Element를 줄일 수 있는 몇 가지 라이브러리를 도입하고자 합니다(npm rank).
    • react-virtualized, React Window, react-infinite-scroller 등
    • CSM Node가 단순 리스트 형태가 아니라 특정 라이브러리는 제한될 것으로 판단되어 여러 라이브러리를 시도해볼 예정입니다.
    • 이와 유사한 라이브러리를 사용해보셨거나 기능을 구현해 보신 분들의 의견 여쭙습니다. 🙌

불필요한 렌더링 억제

• 현재는 Context API에 의해 발생하는 것이기에 상태관리 라이브러리를 도입하여 선택적 구독 시 해결될 것으로 예상됩니다([view] 상태관리도구 도입 관련 논의 #626).
  • 렌더링 최적화 시 대규모 레포지토리 대응에도 도움이 될 것이라 판단됩니다.

---

View 성능 최적화 팀 구성원 모두 위와 같은 작업이 처음이에요. 여러분들의 작은 경험 공유도 큰 도움이 됩니다! 자유롭게 comment 주시면 감사하겠습니다. 😆

[bbanderson]

현재 githru에 필요한 기능이네요~
저는 react-window만 사용해보았는데, 현재 보이는 스크롤만큼만 DOM으로 렌더링해주다보니 실제로 엄청 빨라져서 놀랐어요!
다만 <List /> 컨테이너의 경우, 크기를 고정시켜야 한다는 점과 children으로 render prop(함수 형태)을 사용한다는 점은 비교적 덜 직관적이었어요.
스크롤을 통한 추가 fetching 로직과 잘 섞으면 되겠네요..!