[4팀 윤영서] [Chapter 1-3] React, Beyond the Basics

[YeongseoYoon-hanghae]

과제 체크포인트

기본과제

• shallowEquals 구현 완료
• deepEquals 구현 완료
• memo 구현 완료
• deepMemo 구현 완료
• useRef 구현 완료
• useMemo 구현 완료
• useDeepMemo 구현 완료
• useCallback 구현 완료

심화 과제

• 기본과제에서 작성한 hook을 이용하여 렌더링 최적화를 진행하였다.
• Context 코드를 개선하여 렌더링을 최소화하였다.

과제 셀프회고

기술적 성장

Object.prototype.hasOwnProperty()와 Object.is()를 통한 비교

hasOwnProperty는 객체의 특정 프로퍼티가 객체 자신의 속성인지 확인하는 메서드로, 객체 자신의 고유한 속성만을 비교합니다.
실제로 리액트의 shallowEquals 또한 hasOwnProperty를 통해 구현되어 있습니다.

// React의 코드
  for (let i = 0; i < keysA.length; i++) {
    const currentKey = keysA[i];
    if (
      !hasOwnProperty.call(objB, currentKey) ||
      !is(objA[currentKey], objB[currentKey])
    ) {
      return false;
    }
  }
  
  // 제가 작성한 코드
    for (const key of keysA) {
    if (
      !Object.prototype.hasOwnProperty.call(objB, key) ||
      (objA as Record<string, unknown>)[key] !==
        (objB as Record<string, unknown>)[key]
    ) {
      return false;
    }
  }

리액트의 shallowEquals코드 일부와 제가 작성한 shallowEquals 코드 일부입니다.
두 로직의 공통점은 기본 로직에 있습니다. objA의 키를 모두 순회하면서 키가 objB의 키인지를 비교하고, 값이 같은지 판별합니다.

차이점은 리액트에서는 Object.is를 통해, 제가 작성한 코드에서는 단순 참조 비교 ===를 통해 비교한다는 것입니다.
===는 단순히 참조만 비교하여 객체, 배열 등의 내부 값까지는 비교하지 못하기 때문에 Object.is를 사용하여 비교하면 좀 더 깊은 비교가 가능합니다.
실제로 리액트 공식문서에서도 Object.is를 통해 비교한다는 것이 나와있음에도 이를 간과하여 과제 후 수정하였습니다.

memo

처음에는 다음과 같이 코드를 작성했습니다.

export function memo<P extends object>(
  Component: ComponentType<P>,
  _equals = shallowEquals,
): ComponentType<P> {
  const MemoizedComponent = function (props: P) {
    const prevPropsRef = useRef(props);
    const memoizedComponent = useRef<ReactNode | null>(null);

    if (!memoizedComponent.current || !_equals(prevPropsRef.current, props)) {
      prevPropsRef.current = props;
      memoizedComponent.current = <Component {...props} />;
    }

    return memoizedComponent.current;
  };

  return MemoizedComponent;
}

이렇게 작성하니 테스트는 통과했지만 useRef를 두 번 사용하여야 했고, 기존 준일님께서 주셨던 과제는 tsx가 아닌 ts였음에도 위와 같이 코드를 작성하니 tsx로 변경을 해야만 했습니다.

그래서 다음과 같이 수정하였습니다.

export function memo<P extends object>(
  Component: ComponentType<P>,
  _equals = shallowEquals,
): ComponentType<P> {
  let prevProps: P | null = null;
  let memoizedElement: ReturnType<typeof createElement> | null = null;

  const MemoizedComponent = function (props: P) {
    if (!prevProps || !_equals(prevProps, props)) {
      prevProps = props;
      memoizedElement = createElement(Component, props);
    }

    return memoizedElement;
  };

  return MemoizedComponent;
}

이렇게 작성하니 ts를 tsx로 변경해 줄 필요도 없었고, useRef를 두 번 사용할 필요도 없어졌습니다.

학습 효과 분석

리액트를 사용하면서도 내부 구현이 어떻게 되어있는지, 최적화는 어떻게 진행되는 지에 대해 생각하지 않고 사용하고 있었는데, 과제 덕분에 리액트 내부 구현도 살펴보며 리액트에 대해 더욱 이해할 수 있게 되었습니다.

리뷰 받고 싶은 내용

memo

앞서 말씀드린 memo관련 코드입니다.

export function memo<P extends object>(
  Component: ComponentType<P>,
  _equals = shallowEquals,
): ComponentType<P> {
  let prevProps: P | null = null;
  let memoizedElement: ReturnType<typeof createElement> | null = null;

  const MemoizedComponent = function (props: P) {
    if (!prevProps || !_equals(prevProps, props)) {
      prevProps = props;
      memoizedElement = createElement(Component, props);
    }

    return memoizedElement;
  };

  return MemoizedComponent;
}

위와 같이 작성한 코드는 tsx로 파일을 변경하지 않아도 되고, useRef를 여러개 사용하지 않아도 되나 기존 과제에 달려있던 주석인
// 1. 이전 props를 저장할 ref 생성을 위배(?)한다는 점이 조금 찝찝하게 느껴집니다.

위와 같이 구현해도 memo가 지향하는 방향은 같다고 볼 수 있을까요?

폴리필에 대하여

사실 이번 과제의 주 내용은 아닙니다만 폴리필에 관하여 궁금한 점이 있습니다.
이번 과제를 진행하면서, 리액트에서는 Object.is() 및 Object.prototype.hasOwnProperty()를 자체적으로 폴리필하여 사용하고 있다는 사실을 알게 되었습니다.

저희 회사에서도 최근 JS에 추가된 메서드를 안전하게 사용하기 위해 폴리필을 진행해보자는 의견이 있었기 때문에 이번 과제를 통해 진행해보자는 생각에 진행하였습니다.

1. 현재로서는 vitejs의 plugin-legacy 라이브러리를 설치하여 진행하였는데요. 이 방법이 실무에서 많이 사용되는 방법일까요? 여쭙는 사유는, 리액트에서는 자체적으로 Object.is 등과 같은 메소드의 폴리필을 구현하여 사용하고 있어, 직접 폴리필을 구현하여 사용하는 방식이 좀 더 안정적이고 많이 선호되는 방식인지 궁금해서 입니다.
2. 폴리필을 처음 진행해 보았는데, 다음과 같이 라이브러리를 설치하고 폴리필 관련 설정 후 어플리케이션의 진입점에 import 해주는 방식이 맞을지요?
3. 폴리필의 targets를 정해줄 때 기준이 궁금합니다. 현재로서는

• 전 세계 사용률 1% 이상
• 최근 2개 버전
• 24개월 이내 업데이트
• IE 10 이하 제외
  로 설정하였는데, 실무에서 어떻게 기준을 세워 정하는지 궁금합니다.