개요

원티드 프리 온보딩 4주차 과제에 대한 회고록이다. 3주차는 과제가 없었고 4주차는 2주차때 했던 과제와 마찬가지로 기업과제인데 다른 기업의 과제이다. 하지만 검색창과 관련된 부분은 비슷한 내용이었다. 이번 과제는 특이하게 미리 짜여진 코드가 주어지고 리팩토링 후 기능을 구현하라는 것이었다. 하지만 기존에 제공된 코드는 건들지 않고 기능만 구현하는 것에 익숙해져 있어 무의식적으로 마음에 안든 부분이라도 그대로 내버려 두는 경우가 있었다. 이 부분은 익숙해질 필요가 있을 것 같다.

package manager 오류

패키지 매니저의 peer dependency와 관련해서 오류가 있었다. 이는 npm 7 버전에서 발생하는 오류인데, 모듈에서 요구하는 라이브러리의 버전과 현재 내 프로젝트의 라이브러리 버전이 맞지 않아서 발생한다고 한다. 무슨 말이냐고? 나도 몰라.
서 찾아봤다.

• Dependencies
  런타임과 빌드타임, 개발중 모두에서 이 종속성 패키지들이 필요하기 때문에, 앱이 빌드 될 때 이 종속성 패키지들이 번들에 포함되어 배포된다.

• Dev Dependencies
  런타임에서는 필요하지 않고 빌드타임 & 개발중에만 필요한 패키지들이다. 빌드타임에서 이 종속성들은 빌드에 도움을 주거나 참조가 되지만, 번들에는 포함되지 않는 종속성 패키지들이다.

• Peer Dependencies
  실제로 패키지에서 직접 require(import) 하지는 않더라도 호환성이 필요한 경우 명시한다.

간단히 설명하자면 A 프로젝트에서 이미 react 18버전을 쓰고 있고 B라는 새로운 라이브러리를 다운받았는데 해당 라이브러리가 내부적으로 react 17을 쓰고 있을 경우 충돌이 나는 것이다. yarn과 npm 7이전에는 이를 경고만 하는데 npm 7 이후 부터는 에러로 띄워 설치가 되지 않아 아래의 해결방법들을 통해 해결해야 한다.

해결 방법은 두 가지다.

npm을 유지하는 방법

npm을 계속 써야하는 상황이면 또 2가지 방법으로 나뉜다.

추가 커맨드 입력

--force 나 --legacy-peer-deps를 마지막 부분에 입력해주면서 설치하면 해결이 된다.

--force를 하면 package-lock.json에 몇가지의 다른 의존 버전들을 추가한다.
--legacy를 하면 peerDependency가 맞지 않아도 일단 설치한다.

이 방법들은 급할 땐 괜찮으나 이후로도 자잘한 에러 및 매번 설치할 때 해당 명령을 쳐줘야 하는 등의 문제가 있다.
고 한다. 안해봐서 모르겠다.

peerDependency에 맞추기

이 라이브러리를 꼭 써야 한다면 라이브러리의 내부 모듈 버전들을 내가 변경할 수 없으니 내 프로젝트의 라이브러리를 다운그레이드나 업그레이드해서 버전을 맞추는 방법이다. 개인적으로 라이브러리 주제에 자신한테 맞추라니 주객전도라 기분이 별로 안 좋아 쓰지 않았다.

yarn을 쓰는 방법

npm을 다운그레이드 하면 될 수 도 있겠지만 그 방법 또한 라이브러리에 맞춰 내 프로젝트를 깎아내리는 느낌이라 마음에 들지 않는다. 그냥 yarn을 쓰면 바로 해결되므로 yarn을 사용했다.

memory-leak 관련 오류

컴포넌트가 언마운트 되었는데 해당 컴포넌트의 상태를 변경하려고 할 때 에러가 발생하는 에러이다. 주로 try-catch-finally문에서 try에서 컴포넌트가 사라졌는데 finally에서 상태를 변경하면 문제가 생긴다.

해결 방법은 두가지인데

useEffect의 clean up 함수

clean up 함수로 상태 변경 함수를 실행시켜주면 해결된다. 하지만 이 방법은 코드를 추가해야 돼서 굳이 finally에서 변경할 필요가 없다면 아래와 같은 방법이 더 나은 것 같다.

로직 변경

상태를 변경하는 로직을 finally가 아니라 컴포넌트가 언마운트 되기 전에 실행하도록 로직을 변경 하는 것이다. 필자는 이 방법을 택했다.

useRef type 문제

useRef와 관련해서 type 문제를 겪었다. useRef는 어떻게 호출하냐에 따라 아래와 같이 type이 갈린다.

1. 제너릭(T)과 동일한 타입(T)을 인자로 제공하면 MutableRefObject<T>를 반환하고 이는 current 값을 변경 가능하다. ex) useRef<T>(T)
2. 제너릭에 T를 넣고 인자에 null을 넣으면 RefObject<T>를 반환한다. RefObject는 MutableObject와 다르게 current 값을 변경하지 못한다. ex) useRef<T>(null)
3. 제너릭에 T를 넣고 인자를 비우면 MutableRefObject<T | undefined>를 반환한다. ex) useRef<T>()

무한 스크롤 문제

무한 스크롤을 구현하는데 있어 2가지 방법이 있다.
일단 bottom 탐지는 아래와 같이 할 것이다.

const isAtBottom = scrollTop + clientHeight === scrollHeight;

문제는 맨 밑에 도달시 api를 호출할텐데 어떻게 살짝만 움직여도 수십번 발생하는 스크롤 이벤트의 호출 횟수를 줄이냐는 것이다.

1. Throttling
   • 지정된 시간동안 이벤트가 한 번 밖에 발생하지 않는 것이다.
   • 보통 lodash 같은 라이브러리를 쓰지만 사용 금지라 useState를 이용해 직접 구현했다.
   • 하는 김에 debounce도 같이 첨부한다. 디바운싱은 연속적으로 입력된 이벤트 중 마지막으로 입력 된 이벤트에서 지정된 시간이 지날동안 추가 입력이 없으면 마지막 이벤트만 발생시키는 거다.

export const useDebounce = (time: number) => {
  const [debounce, setDebounce] = useState(0);

  return (fnc: (...args: never[]) => unknown) => {
    if (debounce !== 0) clearTimeout(debounce);
    setDebounce(setTimeout(fnc, time));
  };
};

export const useThrottle = (time: number) => {
  const [isThrottle, setIsThrottle] = useState(false);

  return (fnc: (...args: never[]) => unknown) => {
    if (isThrottle) return;
    setIsThrottle(true);
    setTimeout(() => {
      fnc();
      setIsThrottle(false);
    }, time);
  }
};

2. Intersection Observer API
   • 특정 요소가 뷰포트에 포함되어 화면에 보이는가를 탐지하는 방법이다.
   • 이 방법도 매우 좋다. 비동기로 작동하여 메인 스레드에 영향도 없고 Lazy loading 및 무한 스크롤 등 다양한 경우에 사용할 수 있다.
   • 추가로 scroll 이벤트는 offSetTop 값을 구해오는 과정에서 reflow가 일어나는데 Intersection Observer를 사용하면 scroll 이벤트를 사용하지 않아 reflow가 발생하지 않는다.
   • 다만 여러 기능이 있고 요구사항에서는 무한스크롤시 api 호출이 여러번 되지 않게 하라는 요구였기에 단순 무한 스크롤의 이벤트 횟수 조절하는 용도로 쓰기에는 오버킬이라는 생각이 들어 쓰로틀링을 사용했다. 하지만 성능적인 측면을 고려한다면 이걸 쓰는게 맞는 것 같다.