프로젝트 회고

 특별히 신경 쓴 부분
 - 시맨틱태그 준수
 - 라이트 하우스로 성능, SEO 점검
 - profile로 화면전환, layout shift 점검
 - 서버 응답 시간이 "유독" 긴 페이지에는 로딩바를 추가
 - 모달 컴포넌트를 portal에서 호출하기
 - 불필요한 네트워크 요청 없애기

감정 :
작년 12월부터 작업한 프로젝트가 드디어 끝이 보인다..
개인적으로 지금까지 했던 업무중 제일 힘들었던 프로젝트였던거 같다.
작업량도 많았고, 회사 분위기도 여러가지 사내 이유로 좋지 않았다.
그 와중에 나는 이 프로젝트를 하면서 새롭게 적용해보고 싶은 것들이 많았고 (ex: context + portal 모달, light house 점검) ...
결과적으로는 고생한 보람이 매우매우 컸다!

괴로운 순간들을 이겨낼 수 있었던건 새로운 배움과 체득의 순간들 뿐이었다.

업무적 결과 :
1. 내가 따로 공부하고, 고민했던 부분이 결국 재사용/생산성에 도움이 되어서 많은 작업량을 감당할 수 있었던 거 같다. 6개월 전의 나였으면 못했을 것
대표적인 결과로는 모달 컴포넌트의 중앙화와 여러개의 모달을 겹쳐서 사용할 수 있게 만든 것이다.
2. 화면전환할 때마다의 덜컹거림을 모두 찾아내서 제거하기
-> 이건 정말, 프론트엔드 개발자로써 참을 수가 없었다.
이 부분도 예전의 나라면 하고싶어도 시간이 부족하고, 생각이 부족하여서 할 수 없는 작업이었다.

• 아주 작은 깜박임 잡아내기 : profile 툴로 측정
  : 측정 후 찍히는 스크린샷을 찬찬히 살쳐보면, 특정구간에서 화면에 무엇이 생겼다가 사라지는 그런 이상한 화면이 있다. 그 구간을 보면서 트리거를 찾아낸 후 제거/해결해주는 방식으로 사용하였다.
  원인1 : useState -> 과한 useState 사용은 정말 지양해야한다고 생각한다.
  원인2: 사용한 외부 라이브러리 컴포넌트의 "내가 예상치 못한" 렌더,동작
• layout shift 없애기 : 이 또한 profile로 발견할 수 있었다.
  이 문제는 동적으로 사이즈가 변경되는 UI컴포넌트에서 발생한건데, 호출한 데이터를 전달받기 전, 데이터 주변 UI 컴포넌트 먼저 렌더 되는 경우 가 그랬다. -> useQuery의 isFetching으로 분기 처리 + 데이터와 UI 동시에 렌더시키기
• 데이터 fetch될 때마다 각기 다른 데이터량으로 인해 스크롤바 길이의 변화 :
  -1. 데이터 fetch 전 스크롤바 길이
  -2. 데이터 fetching 중 로딩바 컴포넌트를 보여줄때의 스크롤바 길이
  -3. 데이터 fetch 후 새 데이터량에 따른 스크롤바 길이
  => 이 3가지 상황의 높이값이 모두 고정으로 같을 순 없다.
  그렇다면 적어도 이 셋의 스크롤바 길이가 비슷해야 화면의 덜컹거림이 최소화 된다. 평균치 값을 구하여서 min-hight로 주었더니 많이 좋아졌다.

3. light house로 웹페이지 점검
   : 이 도구의 존재는 인식하고 있었지만, 어떻게 사용하는건지는 잘 몰랐는데.. 원티드 1월 프리온보딩 강의를 듣고 + 추가적으로 더 자료조사하여서 사용해보았다.
   
4. 불필요한 네트워크 호출 잡아내기
   : 나는 업무를 일단 다 했는데, 다른 분들 작업이 지연되는 날들이 있었다. 이 기간동안 내 작업 무한점검을 수행하였다. 화면점검이 어느 정도 마무리된 시점이었어서 그냥 큰 의미없이 네트워크탭 켜놓고 모든 작업을 하나하나 수행해보았는데.. 아니 왠걸?! 이 때 논리상, 흐름상 하지않아도 될 네트워크 호출이 더러 있는 것을 발견하였다.
   -1. 똑같은 요청 2번씩 하는 경우 : useState로 인한 렌더링 -> 사이드 이펙트
   -2. 닫기 버튼을 누르면 수정사항들이 반영된 화면을 자동 refetch -> 수정한 사항이 없어도 refetch됨
   -3. 숨겨진 탭버튼 UI에서 데이터 요청을 하고 있는 경우