[TIL] 0607 | React with Redux, Next.js, TypeScript

목차

• 요약
• State 및 컴포넌트 자세히 살펴보기
• State 스케줄링 및 일괄 처리 이해하기
• useMemo()로 최적화하기

✧ 요약

• 리액트 앱에서는 컴포넌트를 통해 작업을 수행한다. 그리고 최신 리액트에서는 주로 함수 컴포넌트를 사용할 것이다. 이런 컴포넌트(ex. App)는 결국 하나의 작업을 수행할 것이며, JSX 코드를 반환한다.

return (
  <div className="app">
    <h1>Hi there!</h1>
    <DemoOutput show={showParagraph} />
    <Button onClick={allowToggleHandler}>Allow Toggling</Button>
    <Button onClick={toggleParagraphHandler}>Toggle Paragraph!</Button>
  </div>
);

• 이것은 리액트에게 컴포넌트의 출력이 무엇인지를 알려준다. 이런 리액트 컴포넌트에서는 상태(state)와 props, 컨텍스트를 이용해서 작업할 수 있다. 그리고 props와 컨텍스트는 결국 상태(state)의 변경으로 이어지기 때문에 컴포넌트의 변경과 혹은 컴포넌트에 영향을 주거나 어플리케이션 일부에 영향을 미치는 데이터를 변경하게 된다.

컴포넌트에서 상태(state)를 변경할 때마다 컴포넌트는 재평가 된다

• 컴포넌트에서는 상태(state)를 변경할 때마다 이 변경된 상태(state)를 가지고 있는 컴포넌트는 재평가 될 것이다. 즉, 이 말은 컴포넌트 함수가 상태(state)가 변경될 때마다 재실행 된다는 의미이다. 따라서 컴포넌트가 재실행 될 때마다 컴포넌트 내부의 모든 코드 역시 재실행되고, 새로운 출력 값을 얻게 된다. 물론 출력 값은 이전과 동일할 수 있지만 실제로는 다른 의미를 가진다. 예를 들어, 단락 전체가 렌더링 되거나 안될 수도 있다는 의미이다.

<DemoOutput show={showParagraph} />

• DemoOutput 와 같은 컴포넌트를 예를 들어보자.

const DemoOutput = (props) => {
  console.log("DemoOutput RUNNUNG");
  return <MyParagraph>{props.show ? "This is New!" : ""}</MyParagraph>;
};

• 여기 DemoOutput 컴포넌트 내부의 텍스트("This is New!")는 렌더링되지 않을 수도 있다. 리액트는 단순히 최신 평가의 결과를 가져와서 직전 평가의 결과와 비교해서 리액트의 DOM에 전달한다. 그리고 이는 모든 컴포넌트에 해당 된다.

리액트 DOM의 변경 사항은 브라우저의 실제 DOM 에 적용 된다

• 리액트는 최신 평가 결과와 직전 평가 결과와 비교해서 실질적으로 업데이트 되는 부분을 체크한 뒤 리액트 DOM에 전달한다. 그리고 이 리액트 DOM을 통해 index.js 파일을 렌더링하고 리액트 DOM은 이 변경 사항을 브라우저의 실제 DOM에 적용하며, 변경되지 않은 것들은 그대로 둔다.

return (
  <div className="app">
    <h1>Hi there!</h1>
    <DemoOutput show={showParagraph} />
    <Button onClick={allowToggleHandler}>Allow Toggling</Button>
    <Button onClick={toggleParagraphHandler}>Toggle Paragraph!</Button>
  </div>
);

• 이제 리액트가 컴포넌트를 재평가 할 때 단순히 컴포넌트 재평가에서 그치지 않고 전체 함수를 재실행하고 이를 통해 코드 전부를 리빌드한다. 이 JSX 코드가 최신 스냅샷의 출력 결과를 리빌드 하는 것이다. 그리고 이 JSX 코드에 있는 모든 컴포넌트를 재실행한다. 위의 코드에서는 DemoOutput 컴포넌트와 아래의 Button 컴포넌트 두개를 재실행 할 것이다.

const DemoOutput = (props) => {
  console.log("DemoOutput RUNNUNG");
  return <MyParagraph>{props.show ? "This is New!" : ""}</MyParagraph>;
};

export default React.memo(DemoOutput);

• 하지만 이제 DemoOutput는 React.memo를 통해 하위 컴포넌트의 불필요한 재실행을 막았고, 리액트에게 props가 실제로 변경되었을 때만 컴포넌트 함수를 재실행하고 새로운 값이 없을 땐 함수를 재실행하지 않도록 할 수 있게 되었다.

컴포넌트의 재평가는 컴포넌트 함수 전체의 재실행을 의미한다

• 컴포넌트의 재평가는 컴포넌트 함수 전체의 재실행을 의미한다. App 컴포넌트 안에 있는 모든 것들이 다시 실행된다는 사실을 알지 못한다면 우리는 이상한 결과를 초래할 수 있을지도 모른다. 예를 들어보자. 함수 안에 함수를 만들고 해당 함수를 props를 통해 컴포넌트에 전달하면 새로운 함수 객체를 얻을 수 있다. 이렇게 되면 React.memo를 통한 불필요한 재실행을 막을 수 없을 것이다. 앞서서 설명했듯이 객체(배열, 함수)는 참조 값이며, React.memo가 내부적으로 실행하는 일반적인 비교 연산자를 통한 비교는 이 참조 값에 대해서는 통용되지 않기 때문이다.

"React.memo() 가 하는 일은 props 의 값을 확인하고, 이전의 props 와 가장 최근의 props 스냅샷을 비교한다. 그리고 이 비교 작업은 일반적인 비교 연산자를 통해 이뤄진다. 일반적인 원시 값이라면 이런 일반적인 비교 연산자를 통해서 비교가 가능할 것이다. 하지만 배열이나 객체, 함수를 비교한다면 말이 달라진다. 배열이나 객체, 함수는 참조 값이기 때문에 일반적인 비교 연산자를 통해서는 동일한 값으로 취급하지 않기 때문이다."

• 그래서 우리는 useCallback를 사용했다. 바로 이 useCallback을 통해 참조 값도 비교하여 불필요한 재실행을 막을 수 있도록 한 것이다.

"useCallback 은 기본적으로 컴포넌트 실행 전반에 걸쳐 함수를 저장할 수 있도록 하는 hook 으로써 useCallback를 통해서 감싼 함수를 저장하여 이 함수가 어플리케이션이 매번 실행될 때마다 재생성할 필요가 없다는 것을 React에 알리는 역할을 한다. useCallback을 사용하여 특정 함수를 감싼다면, 이 함수 객체가 메모리의 동일한 위치에 저장되므로 이를 통해 비교 작업을 할 수 있게 된다. "

• useCallback을 통해 리액트에게 useCallback으로 특정 함수를 감싸서 함수를 저장하도록 하고, 해당 함수가 재실행되어도 특정 의존성이 변경되는 것이 아니라면 함수 재생성을 막을 수 있다.

✧ State 및 컴포넌트 자세히 살펴보기

• 리액트에서 상태(state)는 가장 중요한 개념이다. 이 상태(state)라는 것은 컴포넌트를 다시 렌더링하고, 화면에 표시되는 것들을 업데이트 해준다. 따라서 컴포넌트와 이 상태(state)와의 상호작용은 리액트의 핵심 개념이라 할 수 있다.

상태(state)와 컴포넌트

• 상태(state)와 컴포넌트 모두 리액트가 관리한다는 것에 주목할 필요가 있다. 이러한 컴포넌트의 개념은 리액트 라이브러리에서 나온 것이며, 리액트는 이 컴포넌트와 연결된 상태(state)도 함께 처리하기 때문이다. useState hook 을 사용하는 게 바로 그 예시가 될 수 있다. useState를 통해 컴포넌트와 상태(state)간의 상호 작용을 처리한다.

useState는 가장 일반적인 형태의 상태(state) 관리 방법이다

• 가장 일반적인 형태의 상태(state) 관리는 useState 훅을 이용하는 것이다. useState를 이용하면 새로운 상태(state)를 만들어서 자동적으로 useState를 호출한 컴포넌트에 이를 연결할 수 있기 때문이다. 그리고 이런 종류의 '연결'도 리액트가 담당하는 역할이다.

• useState를 호출하게 되면 리액트는 백그라운드에서 이를 관리하고, 컴포넌트와 이를 묶어줄 새로운 상태(state) 변수를 만들기 때문이다. 이전의 학습에서도 강조했듯이 useState를 호출했음에도 App 컴포넌트 함수가 매번 다시 실행되는 것은 확실히 이상해 보인다. 왜냐하면 앞서 거론한 문제로 인해서 상태(state)에 대한 어떤 종류의 손실이 발생하거나 상태(state) 초기화가 발생하는 것 같지는 않기 때문이다.

컴포넌트가 업데이트될 때마다 useState 에 전달된 기본 값도 다시 초기화 될까?

• 컴포넌트 함수가 재실행 될 때마다 상태(state) 값은 초기화되지 않는 이유는 간단하다. useState는 리액트가 제공하는 훅이며, 리액트는 상태(state)를 관리하고 컴포넌트와의 연결을 관리한다. 그리고 이 리액트의 관리 프로세스의 일부로 리액트는 useState와 여기에 전달된 '기본 값'에 대해서는 한 번만 고려하도록 처리가 되기 때문이다. 한 번만 고려한다는 말은 무엇일까? 바로 App 컴포넌트(예시)가 최초 실행될 때에만 고려한다는 말이다.

import React, { useState, useCallback } from "react";

function App() {
  const [showParagraph, setShowParagraph] = useState(false);
  const [allowToggle, setAllowToggle] = useState(false);

  ...
}

• App 컴포넌트가 최초 실행되고 useState가 실행되면, 리액트가 관리하는 새로운 상태(state) 변수를 만들게 된다. 그런 후, 리액트는 이 변수가 어느 컴포넌트에 속하는지를 기억해둔다. (우리의 경우에는 App 컴포넌트가 될 것이다.) 그리고 useState에 전달된 기본 값을 사용해서 상태(state) 값을 초기화한다. 이후 App 컴포넌트를 재평가하게 될 때 useState를 호출하게 되면(컴포넌트 함수가 재평가 될 때마다 해당 컴포넌트 함수의 모든 코드들은 재실행-호출 된다.) 새로운 상태(state)는 생성되지 않는다. 리액트는 여기에서 App 컴포넌트에 대한 상태(state)가 이미 존재함을 기억하고 있기 때문에 필요한 경우에만 이 상태(state)를 업데이트하게 된다. App 컴포넌트 함수가 재실행되고 몇 몇의 상태(state)는 업데이트될 수 있기 때문이다. 따라서 리액트는 상태(state)의 관리와 갱신만을 담당한다.

정리

• 해당 컴포넌트가 DOM에서 완전히 삭제되거나 하지 않는 이상 상태(state)의 초기화는 다시 이루어지지 않는다. 게다가 우리가 예시로 들고 있는 App 컴포넌트는 root 컴포넌트이기에 앞서 거론한 예외적인 일은 아예 발생하지도 않을 것이다. 물론 하위 컴포넌트의 경우라면 조건에 따라 렌더링될 수도 있지만 말이다. 예를 들어, 하위 컴포넌트가 삭제되었다가 다시 연결된다면 새로운 상태(state)가 호출되고 다시 초기화될 수 있을 것이다. 하지만 DOM 에 컴포넌트가 연결되고 유지되는 동안에는 상태(state)는 최초의 초기화 이후에는 '갱신'만 된다. 이는 아주 중요한 개념이다. 물론 useReducer에 대해서도 이 개념은 동일하게 적용된다.

✧ State 스케줄링 및 일괄 처리 이해하기

• 지금까지 리액트가 어떻게 상태(state)를 관리하는지에 대해 알아보았다. 하지만 앞서 거론했듯이 강조해야 할 중요한 개념이 있다. 그것은 리액트가 상태(state)에 대한 '갱신'을 어떻게 하는지에 대한 것 말이다.

function MyProduct() {
  const [currentState, setCurrentState] = useState("DVD");
}

• 예시 코드를 한 번 보자. 우리는 MyProduct 컴포넌트가 존재한다. 이 컴포넌트 안에서는 useState 훅을 통해 일부 상태(state)들을 관리할 수 있다. 즉, 리액트가 상태(state)를 관리해줄 수 있다. MyProduct 컴포넌트 내부의 currentState 상태(state)는 'DVD' 라는 문자열 초기값을 가졌다고 가정해보자. 아마도 어떤 어플리케이션이 될지는 모르겠지만 사용자가 버튼을 누르거나 하면서 해당 컴포넌트 안에서 상태(state)가 업데이트되고 갱신될 것이다. 그리고 상태(state) 업데이트 함수인 setCurrentState 를 통해서 새로운 값으로 업데이트 될 것이다.

function MyProduct() {
  const [currentState, setCurrentState] = useState("DVD");

  const buttonClickHandler = () => {
    setCurrentState("BOOK");
  };
}

• 그리고 이제 이 제품을 'DVD'에서 'BOOK'으로 변경하고자 한다. buttonClickHandler 함수에서 발생하는 일은 setCurrentState 가 실행되었음에도 기존의 cuurentState 초기 값인 'DVD' 가 즉각적으로 변경되지 않는다는 것이다. 대신에 상태(state) 업데이트 함수인 setCurrentState 를 호출하면, 'BOOK' 데이터로 상태(state) 업데이트를 하도록 예약을 하게 된다. 이것이 상태(state) 갱신 예약이다.

상태(state) 갱신 예약이란 무엇인가

• 리액트는 상태(state) 업데이트 함수인 setCurrentState 를 호출하고 상태(state) 업데이트가 필요하다는 것을 인지하고 있고 또한 처리할 계획까지 준비하고 있지만 이를 즉시 처리하지는 않는다. 사실 대부분의 경우에는 상태(state) 변경이 발생하면 상태(state) 갱신에 대한 스케줄 작업을 매우 빠르게 발생한다. 거의 즉각적인 거나 다름 없다. 실제로는 순간적으로 발생하는 것처럼 보이며, 사용자 역시 이러한 '지연'에 대해서는 알지 못한다. 하지만 리액트는 이 상태(state) 변화를 '지연' 시키게 된다.

리액트는 상태(state) 변화를 지연 시킨다

• 대다수의 성능 기반의 작업들은 거의 동시에 진행되는데, 잠재적으로 리액트는 더 높은 우선 순위를 갖는 것으로 간주한다. 화면에 사용자가 입력할 수 있는 인풋 창이 있다고 가정해보자. 사용자 입력에 응답하는 것이 화면의 문자를 변경하는 것보다는 더 우선 순위가 높을 것이다. 이러한 이유로 리액트는 예정된 상태(state) 변경을 '지연' 시킬 수 있다.

리액트는 상태(state) 변화가 발생하면 우선순위에 따라 같은 타입임을 보증한다

• 리액트가 하는 일은 상태(state) 변화가 발생하게 되면 이 상태(state) 변화의 순서를 명확하게 해서, 같은 타입 임을 보증하는 것이다. 우리가 앞서 살펴보았던 코드를 다시 보자.

function MyProduct() {
  const [currentState, setCurrentState] = useState("DVD");

  const buttonClickHandler = () => {
    setCurrentState("BOOK");
  };
}

• 즉각 실행이 필수적인 것은 아니다. 결국 언젠가는 처리가 되고 상태(state)는 'BOOK'으로 바뀔 것이다. 그리고 상태(state)가 활성화되면 또 상태(state) 변화가 처리되면 리액트는 컴포넌트를 재평가하고 컴포넌트 함수를 재실행할 것이다.

state의 스케쥴링

• 상태(state)의 스케줄링 때문에 다수의 상태(state) 갱신 예약이 동시에 있을 가능성도 있다. 이 때문에 동시에 여러 번의 갱신이 스케줄 될 수 있으므로, 상태(state)를 갱신할 때는 함수 형태를 이용해서 갱신하는 것을 추천한다. 특히 이전 상태(state) 스냅샷에 의존해야 한다면 말이다.

const toggleParagraphHandler = useCallback(() => {
  if (allowToggle) {
    setShowParagraph((prevParagraph) => !prevParagraph);
  }
}, [allowToggle]);

• 해당 코드는 다른 예시지만, 함수 형태로 상태(state)를 갱신하고 있기에 가져왔다. 사실 많은 경우에 함수 형태로 상태(state)를 갱신하지 않는다고 큰 문제가 되는 일은 별로 없다. 또한 굉장히 빠르게 처리가 되기 때문에 리액트에서 스케줄링으로 인한 '지연' 조차 사용자는 느끼지 못할 가능성이 더 크다. 하지만 이론상으로는 분명 이 스케줄링 작업으로 인한 '지연'이 발생될 수 있으므로 함수 형태로 업데이트 하는 것이 상태(state) 변경이 순서대로 처리되고 이전 상태(state)를 기반으로 매 회 상태(state) 변경이 발생할 때마다 가상 최신의 상태(state)를 얻을 수 있게 해주는 안전한 방법인 것은 명백할 것이다.

함수 형태로 상태(state)를 업데이트하지 않는다면 어떤 결과를 초래할까?

• 만약 함수 형태로 상태(state)를 업데이트하지 않는다면 발생할 수 있는 어떤 가능성이란 무엇일까? 컴포넌트 함수가 마지막으로 실행될 때의 상태(state)를 얻는다는 것은 즉 상태(state) 변경이 순서대로 실행될 때와는 조금 다른 결과를 낳을 가능성이 높다는 뜻이다. 해당 컴포넌트의 재 렌더링 주기는 모두 동일하고 완료되지 않은 상태(state) 변경 작업이 여러 개 있다고 생각해보자. 해당 컴포넌트 내부에 있는 모든 코드들은 최종 컴포넌트 스냅샷으로부터 발생하지만, 당연히 상태(state) 변경 작업이 처리된 경우에는 컴포넌트는 중간에 다시 렌더링 될 것이다. 하지만 상태(state) 변경 작업들은 이미 갱신에 대한 예약이 되어 있기 때문에 완료되지 않은 상태(state) 변경 작업은 새로운 컴포넌트의 결과를 고려하지 않게 된다.

상태(state) 업데이트는 함수 형태로 !

• 상태(state) 업데이트는 함수 형태로 사용해야 리액트가 미완료된 상태(state) 변경 작업에 대하여 최신의 상태(state)를 사용하고 컴포넌트가 재렌더링되었을 그 시점의 상태(state)를 사용하지 않을 수 있게 된다. 이것이 함수 형태를 사용하길 권장하는 이유가 된다. 컴포넌트가 재렌더링 되었을 때의 시점과 상태(state) 변경이 예약되는 시점의 차이를 이해하는 것은 중요하다. 하나의 컴포넌트가 재평가 되면서 미완료된 상태(state) 변경 작업이 여러 개 있을 수 있다. 그리고 이것이 바로 함수 형태로 상태(state) 업데이트를 해야 하는 핵심적인 이유가 된다.

동일한 이슈(가장 최신의 상태(state)를 받아오지 않을 가능성)를 처리하는 또 다른 방법

• 우리가 이전에 useEffect에 대해 학습했던 적을 기억할 것이다.

  section 10 참조

// Reducer의 상태 값을 이용한 객체 구조 분해 할당
const { isValid: emailValid } = emailState;
const { isValid: passwordValid } = passwordState;

useEffect(() => {
  const identifier = setTimeout(() => {
    console.log("Checking form validity!");
    setFormIsValid(emailValid && passwordValid);
  }, 500);

  return () => {
    console.log("CLEANUP");
    clearTimeout(identifier);
  };
}, [emailValid, passwordValid]);

• 이전의 코드에서 useEffect 내부에서 이메일과 비밀번호의 유효 상태(state)를 통해 폼의 유효성을 업데이트하는 것이 좀 더 안전하다고 했던 것을 기억할 것이다. 이전 상태(state)의 스냅샷을 기반으로 상태(state)를 갱신하기 위해 함수 형식을 사용하는 것과 동일하게 useEffect 상태(state) 또는 종속된 값이 변경될 때마다 의존성 메커니즘을 통해 내부에서 선언한 이펙트가 재실행 되도록 하는 방법 말이다. 이를 통해서 컴포넌트 함수가 재실행되면서 매번 리펙트 역시 다시 재실행되기 때문에 미완료된 상태(state) 변경 작업이 빠짐없이 실행된다. 그리고 실제로 이펙트는 이 이후에 실행되기에 이런 작업이 수행될 때마다 가장 최신의 결과를 얻을 수 있게 된다.

두 가지 방법 중에 어떤 것을 선택해서 사용해야 할까?

• 이 두가지 방법은 모두 '가장 최신의 상태(state)를 받아올 수 있도록' 하는 방법들이다. 그리고 이 두가지 방법 중에 어떤 걸 선택하느냐는 우리가 이를 통해서 무엇을 얻고 싶은지에 따라서 달라진다.

상태(state) 갱신 스케줄링을 기억해야만 하는 이유

• 상태(state) 갱신 스케줄링은 꼭 기억해야만 하는 메커니즘이다. 단순히 이 메커니즘을 통해 무언가를 하려고 하는 게 아니며 사실상 스케줄 업데이트 관리는 리액트가 해주고 있지만 말이다. 다만 우리가 데이터 없이 작업을 할 때 발생할 수 있는 잠재적인 위험을 배제하기 위해서 반드시 짚고 넘어가야하는 개념이다. 그리고 이 잠재적 이슈를 방지하기 위해 우리가 선택할 수 있는 두개의 가능성(함수 형태로 상태(state) 업데이트하기, useEffect를 사용하기) 또한 기억해야 한다.

const exampleHandler = () => {
  setFirstState(something1);
  setSecondState(something2);
};

• 예시 코드를 보자. exampleHandler 함수 내부의 두 개의 상태(state) 갱신이 스케줄링 될 것이다. 하지만 컴포넌트 역시 재실행되고 재평가된다는 것도 의미한다. 사실 이것들은 리액트가 하는 역할이 아니다. 이렇게 두 개의 상태(state) 갱신이 같은 코드 조각에 존재한다면, 즉 같은 함수가 서로 다른 프로미스에 있지 않고, 같은 곳에 존재한다면 이 둘 사이에 시간 '지연'과 같은 현상은 발생하지 않는다.

setFirstState(something1);
setSecondState(something2);

• 두 개의 상태(state) 갱신 함수가 같은 곳(exampleHandler)에 위치하고 이 둘 모두 지금과 같이 상태(state) 갱신 함수를 호출한다면 리액트는 이들에 대한 상태(state) 갱신을 하나의 동기화 프로세스에서 같이 실행하게 된다. 예를 들어서, 하나의 함수가 처음부터 끝까지 어떠한 콜백이나 프로미스 없이 실행된다면 리액트는 이 함수로부터 발생하는 모든 상태(state) 갱신 작업을 하나의 상태(state) 갱신 작업으로 처리한다는 뜻이다.

정리

• 하나의 함수 안에서 아예 다른 것으로 업데이트를 한다면 두 개의 상태(state)를 변경하는 하나의 상태(state) 변경 작업 스케줄이 존재하게 된다. 이는 단 하나의 프로세스만을 가지며, 컴포넌트의 재실행-재평가로 인한 두 번의 변경 작업이 아니라 함수 내의 모든 상태(state) 변경을 하나의 작업으로 결합해 놓은 스케줄이란 뜻이다. 따라서 상태(state) 배치 작업은 리액트를 통한 작업에서 반드시 알아야 하는 또 다른 개념이다.

✧ useMemo()로 최적화하기

• useCallback처럼 또 다른 최적화 방법으로 사용할 수 있는 useMemo 훅에 대해서 알아볼 것이다. 그 전에 먼저 예제의 코드에서 우리가 이전에 최적화했던 방법인 useCallback이 어떻게 사용되고 있는지를 하나씩 확인해볼 것이다.

App.js

function App() {
  const [listTitle, setListTitle] = useState("My List");

  const changeTitleHandler = useCallback(() => {
    setListTitle("New Title");
  }, []);

  return (
    <div className="app">
      <DemoList title={listTitle} items={[5, 3, 1, 10, 9]} />
      <Button onClick={changeTitleHandler}>Change List Title</Button>
    </div>
  );
}

• 예제의 App 컴포넌트를 천천히 살펴보자. changeTitleHandler 함수에서 사용하고 있는 useCallback은 기본적으로 함수를 저장하며, 저장된 함수를 다시 재실행하거나 재평가하는 일은 의존성 배열에 의한 변경을 제외하고는 없도록 만들어준다.

<Button onClick={changeTitleHandler}>Change List Title</Button>

• 그리고 Button 컴포넌트에서 onClick props를 통해 해당 함수를 전달하고 있다.

export default React.memo(Button);

• Button 컴포넌트는 내부적으로 React.memo를 사용하며 useCallback을 통해 함수를 저장했기 때문에 버튼의 props 는 변경되지 않으므로 이 Button 컴포넌트는 다시 렌더링 되지 않을 것이다.

• 저장하고 화면을 확인해보면, 리스트가 렌더링 되있는 걸 알 수 있다. 오름차순으로 정렬이 된 채로 말이다. 분명 우리가 작성한 코드에 입력한 데이터는 정렬되지 않은 상태였다. 이 말인 즉슨, 리스트에서 어떤 종류의 정렬을 실행하고 있다는 뜻이다.

DemoList.js

const DemoList = (props) => {
  const sortedList = props.items.sort((a, b) => a - b);

  return (
    <div className={classes.list}>
      <h2>{props.title}</h2>
      <ul>
        {sortedList.map((item) => (
          <li key={item}>{item}</li>
        ))}
      </ul>
    </div>
  );
};

• DemoList 컴포넌트를 확인해보면, 간단한 내장 정렬 메소드(sort())로 리스트를 정리한 것을 알 수 있다. 하지만 컴포넌트 내부에 이런 로직이 있다는 뜻은 성능 면에서 민감할 수 있다는 뜻이기도 하다. 물론 예시 코드처럼 리스트가 짧다면 정렬 속도 역시 빠르겠지만 만약 리스트가 길다면 혹은 다른 작업을 수행하는 중이라면 분명 긴 시간을 소요하는 로직이 될 수도 있을 것이다. 전체 컴포넌트가 재평가될 때마다 이런 긴 시간을 소요하는 로직을 실행하고 싶지 않다면 어떻게 해야 할까? 이전의 학습에서 불필요한 재평가 과정을 피하는 여러 방법들을 알아봤다. React.memo가 바로 그 예시 중에 하나일 것이다.

const DemoList = (props) => {
  const sortedList = props.items.sort((a, b) => a - b);

  return (
    <div className={classes.list}>
      <h2>{props.title}</h2>
      <ul>
        {sortedList.map((item) => (
          <li key={item}>{item}</li>
        ))}
      </ul>
    </div>
  );
};

export default React.memo(DemoList);

• 먼저, 불필요한 재렌더링을 피하기 위해 DemoList 컴포넌트를 React.memo로 감싸주었다. 이렇게 하면 불필요한 동작을 막을 수 있을 것이다. DemoList 컴포넌트 내부에 콘솔 로그로 "DemoList RUNNING"를 출력하는 코드를 추가하고 개발자도구에서 한 번 확인해보자.

• 당연히, 초기 화면에서는 이 "DemoList RUNNING"를 확인할 수 있다. 즉 리스트가 정렬되었다는 의미이기도 하다. 하지만 그 뒤에는 실행되지 말아야 한다. 버튼을 누르고 페이지의 제목이 바뀐다. 그리고 이 제목은 리스트의 일부분이다. 따라서 버튼을 클릭하면 DemoList 컴포넌트가 재실행되는 것이다. props 의 일부가 바뀌었기 때문에 제목이 변경된 것이니 당연히 재실행 되어야 마땅하다. 제목은 실제 값의 변경이 일어났으므로 React.memo는 정상 작동하고 있는 것이다. 앞서 props의 일부가 바뀌고 실제 값의 변경이 일어났기 때문에 React.memo로 감싸도 당연히 재실행을 수행한다.

• 물론, 현재는 부모 컴포넌트(App)가 재렌더링 되었으니 언제나 다시 실행이 되는 것이다.

<DemoList title={listTitle} items={[5, 3, 1, 10, 9]} />

• App 컴포넌트 내부의 코드에서 DemoList에 전달하는 items props의 배열이 부모 컴포넌트(App) 컴포넌트가 실행될 때마다 지속적으로 재생성되기 때문이다. 따라서 제목이 바뀌지 않더라도 상위 구성 컴포넌트가 여타 이유로 재실행되면 새로운 배열([5, 3, 1, 10, 9])을 생성하기 때문에 DemoList 컴포넌트는 당연히 다시 실행된다. 함수와 마찬가지로, 배열 역시 객체이고 이 객체는 참조 값이기 때문이다.

• 따라서 제목이 바뀐다는 것은 DemoList를 리빌드 해야 하는 타당한 이유가 될 것이다. 하지만 과거에 했던 모든 작업들을 반복하고 싶지 않을 때도 있는 법이다. 특히 다시 해야 할 작업이 성능에 민감한 작업이라면 말이다. 또한, 정렬은 컴포넌트에서 수행 가능한 대표적인 성능 집약적 작업 중에 하나이다.

정렬 작업에서 성능 최적화 하기

• 이에 대한 해결책이 있을까? 이전처럼 useCallback을 사용하여 함수 객체를 저장하고 입력 값이 변경될 경우에만 리빌드할 수도 있다. 다른 종류의 데이터에도 비슷한 역할을 하는 훅이 있다. 바로 useMemo 이다.

useMemo 로 성능 최적화 하기

• useMemo는 기본적으로 저장을 할 수 있는데, useCallback이 함수에 대한 것을 저장하듯이 모든 종류의 데이터를 저장하는 기능을 가지고 있다.

const sortedList = props.items.sort((a, b) => a - b);

• 우리가 데이터를 정렬했던 로직이다. 이 정렬하는 로직을 useMemo를 사용하여 저장하고, 최적화를 할 것이다.

const sortedList = useMemo(() => {
  return props.items.sort((a, b) => a - b);
});

• 먼저 useMemo를 호출하여 해당 정렬의 결과를 기억하게 할 수 있다. 그리고 useMemo의 첫 번째 인자에는 함수가 들어가야 한다. 이 말인 즉슨, useMemo가 함수를 기억하도록 하는 것은 아니며, 단지 함수가 저장하고 싶은 것을 반환하고 이 반환된 결과 값을 저장하도록 할 뿐이다. 이 경우에는 정렬된 배열을 반환할 것이다.

const sortedList = useMemo(() => {
  return props.items.sort((a, b) => a - b);
}, []);

• useCallback 과 마찬가지로 useMemo는 두 번째 인자가 필요한데, 이는 역시 의존성 배열이다. 이 의존성 배열을 통해 저장된 값에 변경 사항이 생길 때마다 useMemo에 저장된 값을 업데이트할 것이다. 여기서는 값이 변경되고 새로운 값이 추가될 때마다 업데이트 되도록 할 것이다.

const sortedList = useMemo(() => {
  return props.items.sort((a, b) => a - b);
}, [props]);

• 해당 의존성 배열에 props를 추가할 수도 있지만(props의 items 이기 때문이다.) 이는 전체 props 객체가 여기에서의 의존성 객체가 되며, 이는 항상 재계산 되기 때문에 다른 방법을 고려하는 것이 좋을 것이다.

const { items } = props;

const sortedList = useMemo(() => {
  return items.sort((a, b) => a - b);
}, [items]);

• 이전보다 좀 더 우아하게 의존성 배열을 사용하기 위해서는 앞서 배웠던 객체 구조 분해 할당을 사용할 수 있을 것이다. props에서 객체 구조 분해 할당을 이용해서 items를 꺼내오고, 이것을 useMemo의 의존성 배열에 추가한다. props 로 items를 직접 꺼내와서 정렬해주었던 로직도 그냥 items로 수정해준다. 이제 useMemo의 로직은 의존성 배열인 items에 변경 사항이 발생할 때만 리빌드를 진행할 것이다.

const sortedList = useMemo(() => {
  console.log("Items sorted");
  return items.sort((a, b) => a - b);
}, [items]);

• useMemo가 반환하는 함수 내부에 "Items sorted"를 출력하는 콘솔 로그를 추가하고 저장한 뒤 개발자 도구 콘솔을 확인해보자.

• 새로 고침을 하면 최초 실행이 되면서 "Items sorted"를 출력하는데, 제목을 변경해도 여전히 "Items sorted"를 출력하는 것을 알 수 있다. 생각대로 구동되지 않고 있는 것이다. 왜 그럴까?

• 이전에도 말했듯이, useMemo의 의존성 배열인 items가 바뀌었기 때문이다.

<DemoList title={listTitle} items={[5, 3, 1, 10, 9]} />

• 여기서 props 로 전달하는 items는 App 컴포넌트가 재실행될 때마다 새로운 배열을 생성하기 때문에 이 배열 역시 재생성 된다. 그러니까 기술적으로는 같은 값을 가지고 같은 순서로 된 비슷한 배열이지만, 메모리상에서는 새로운 배열이기 때문에 내포한 값이 같더라도 기존 배열과 다른 새로운 배열로 취급한다. 이 배열이 앞서 여러 번 언급했던 참조 값이라는 사실을 잊지 말아야 한다. 따라서 이제 불필요하게 새로운 배열을 전달하는 것을 막기 위해서 이 배열에 useMemo를 사용할 것이다.

useMemo 로 새로운 배열의 생성을 막기

<DemoList title={listTitle} items={useMemo(() => [5, 3, 1, 10, 9], [])} />

• 해당 배열이 있는 위치에 useMemo 함수로 배열을 래핑한다. 그리고 빈 의존성 배열을 추가한다. 이 빈 의존성 배열은 값에 변함이 없다. 외부 의존성이 없고 하드 코딩되어 있다. 따라서 useMemo를 사용할 수 있는 것이다.

const listItems = useMemo(() => [5, 3, 1, 10, 9], []);

• useMemo 함수로 래핑한 배열 값을 변수 listItems에 저장하고,

<DemoList title={listTitle} items={listItems} />

• 아까 배열이 있던 위치에 그 변수를 포인터 시킨다. 이렇게 함으로써 불필요한 재정렬을 막을 수 있을 것이다.

• 저장하고 확인해보자. 최초 실행에는 출력되던 "Items sorted"이 버튼을 누르면 더이상 출력되지 않는 걸 확인할 수 있다. useMemo 덕분에 전달된 배열이 재정렬 되지 않기 때문이다.

정리

• useMemo는 useCallback에 비해 사용빈도가 낮을 것이다. 데이터를 기억하는 것보다 함수를 기억하는 것이 훨씬 더 도움이 되며, 빈도수도 높기 때문이다. 물론 데이터 재계산과 같은 성능 집약적 작업 때문에 데이터를 저장해야 할 필요도 있으나, 이런 경우가 아니라면 사용할 일은 없을 것이다.
• 잊지 말아야 할 사실은, useMemo를 사용하여 데이터를 저장한다는 것은 메모리를 사용한다는 것이며 이런 useMemo를 통한 함수 저장 역시 일정 성능을 사용한다는 뜻이기도 하다는 것이다. 따라서 useMemo는 여러 성능 면에서 고려하여 사용해야 하는 것이다. 다만 지금과 같이 뭔가를 정렬하는 경우라면 이후의 컴포넌트 업데이트에서 불필요한 정렬을 막을 수 있으므로 useMemo를 고려해보는 것도 괜찮을 것이다.

✦ 출처

---

🚨 해당 포스팅은 Udemy의 ⌜React 완벽 가이드⌟ 강의를 베이스로 한 기록입니다.
✍🏻 강의 git repo 바로가기