React 공식문서 이해하기 (25)

Syoee·2023년 12월 5일
React
0

React

목록 보기
25/30
post-thumbnail

Chapter 4. Escape Hatches

#3 Effect와 동기화하기

학습 목차

1. Effect란 무엇이며 이벤트와는 어떤게 다른가?
2. Effect가 필요하지 않을 수도 있다.
3. Effect 작성 방법
4. 개발 환경에서 두 번씩 실행되는 Effect를 처리하는 방법은 무엇인가?
5. 한 곳에 모으기

1. Effect란 무엇이며 이벤트와는 어떤게 다른가?

  • Effect에 도달하기 전에 React 컴포넌트 내부의 두가지 유형의 논리에 익숙해져야 한다.
    • 렌더링 코드(UI 구성하기에서 소개됨)는 컴포넌트의 최상위 레벨에 있다.
      여기서 props와 state를 가져와 변환하고 화면에 표시할 JSX를 반환한다.
      렌더링 코드는 순수해야한다.
      수학 공식처럼 결과만 계산할 뿐 다른 작업은 수행하지 않는다.
  • 이벤트 핸들러(상호작용 추가하기에서 소개됨)는 컴포넌트 내부에 있는 중첩된 함수로, 계산만 하는 것이 아니라 별도의 작업도 수행한다.
    이벤트 핸들러에서는 입력 필드를 업데이트하거나, HTTP POST요청을 제출하여 제품을 구매하거나, 사용자를 다른 화면으로 이동할 수 있다.
    이벤트 핸들러에는 특정 사용자 작업(예:버튼 클릭 또는 입력)으로 인해 발생하는 “사이드 이펙트”(프로그램의 state를 변경함)가 포함되어 있다.
  • 때로는 이것만으로는 충분하지 않을 수 있다.
    화면에 표시될 때마다 채팅 서버에 연결해야 하는 ChatRoom 컴포넌트를 고려해 보자.
    서버에 연결하는 것은 순수한 계산이 아니므로(사이드 이펙트) 렌더링 중에 발생할 수 없다.
    그러나 ChatRoom 표시를 촉발하는 클릭과 같은 특정한 단일 이벤트는 없다.
  • Effect를 사용하면 특정 이벤트가 아닌 렌더링 자체로 인해 발생하는 사이드 이펙트를 명시할 수 있다.
    채팅에서 메시지를 보내는 것은 사용자가 특정 버튼을 클릭함으로써 직접적으로 발생하기 때문에 이벤트이다.
    그러나 서버 연결을 설정하는 것은 컴포넌트를 표시하게 만든 상호작용에 관계없이 발생해야 하기 때문에 하나의 Effect이다.
    Effect는 화면 업데이트 후 커밋이 끝날 때 실행된다.
    이 때가 React 컴포넌트를 일부 외부 시스템(네트워크 또는 서드파티 라이브러리와 같은)과 동기화하기에 좋은 시기이다.

KeyNote

  • 이 글에서 대문자로 시작하는 “Effect”는 위의 React에 한정된 정의,
    즉, 렌더링으로 인해 발생하는 사이드 이펙트를 나타낸다.
    이 후로 더 넓은 프로그래밍 개념을 언급할 때는 “사이드 이펙트”라고 하겠다.

2. Effect가 필요하지 않을 수도 있다.

  • Effect는 일반적으로 React 코드에서 벗어나 일부 외부 시스템과 동기화하는 데에 사용된다는 점을 인지하자.
    여기에는 브라우저 API, 서드파티 위젯, 네트워크 등이 포함된다.
    Effect가 다른 state를 기반으로 일부 state만을 조정하는 경우, Effect가 필요하지 않을 수도 있다.

2-1. Effect 작성 방법

  • Effect를 작성하려면 다음 세 단계를 따라가자.

    1. Effect를 선언한다.
      기본적으로 Effect는 모든 렌더링 후에 실행된다.

    2. Effect의 의존성을 명시한다.
      대부분의 Effect는 렌더링 할 때마다가 아니라 필요할 때만 다시 실행해야 한다.
      예를 들어, 페이드 인 애니메이션은 컴포넌트가 나타날 때만 발동되어야 한다.
      대화방 연결 및 해제는 컴포넌트가 나타났다가 사라지거나 대화방이 변경될 때만 발생해야한다.

    3. 필요한 경우 클린업을 추가한다.
      일부 Effect는 수행중이던 작업을 중지, 취소 또는 정리하는 방법을 명시해야한다.
      예를 들어, “connect”에는 “disconnect”가 필요하고 “subscribe”에는 “unsubscribe”가 필요하며 “fetch”에는 “cancel”또는 “ignore”가 필요하다.

      ! 주의 !

    • 기본적으로 Effect는 매번 렌더링 후에 실행된다.
      그렇기 때문에 다음과 같은 코드는 무한 루프를 생성한다.
      const [count, setCount] = useState(0);
useEffect(() => {
  setCount(count + 1);
});
    • Effect는 렌더링의 결과로 실행된다. state를 설정하면 렌더링을 트리거한다.
      Effect에서 즉시 state를 설정하는 것은 전원 콘센트를 꽂는 것과 같다.
      Effect가 실행되고, state를 설정하면 다시 렌더링이 발생하고, 다시 렌더링이 발생하면 Effect가 실행되고, 다시 state를 설정하면 또 다시 렌더링이 발생하는 식이다.
    • Effect는 보통 컴포넌트를 외부 시스템과 동기화해야 한다.
      외부 시스템이 없고 다른 state를 기반으로 일부 state만 조정하려는 경우 Effect가 필요하지 않을 수도 있다.
    • 의존성 배열이 없는 경우와 비어 있는 [] 의존성 배열이 있는 경우의 동작은 다르다.
      useEffect(() => {
// This runs after every render
// 렌더시마다 실행됩니다.
});
      useEffect(() => {
// This runs only on mount (when the component appears)
// 오직 마운트시(컴포넌트가 나타날 때)에만 실행됩니다.
}, []);
      useEffect(() => {
// This runs on mount *and also* if either a or b have changed since the last render
// 마운트시 뿐만 아니라 a 또는 b가 직전 렌더와 달라졌을 때에도 실행됩니다.
}, [a, b]);

3. Effect 작성 방법

  • React는 개발 환경에서 버그를 찾기 위해 컴포넌트를 의도적으로 다시 마운트한다.
    “어떻게 하면 Effect를 한 번만 실행할 수 있는가”가 아니라 “어떻게 다시 마운트한 후에도 Effect가 잘 작동하도록 수정하는가” 이다.
  • 일반적으로 정답은 클린업 함수를 구현하는 것이다.
    클린업 함수는 Effect가 수행 중이던 작업을 중지하거나 취소해야 한다.
    경험상 (상용 환경에서) 한 번만 실행되는 Effect와 (개발 환경에서의) 설정 → 정리 → 설정 시퀀스를 사용자가 구분할 수 없어야 한다.
  • 작성하게 될 대부분의 Effect는 아래의 일반적인 패턴 중 하나에 해당한다.

4. 개발 환경에서 두 번씩 실행되는 Effect를 처리하는 방법은 무엇인가?

4-1. React가 아닌 위젯 제어하기

  • 때론 React로 작성하지 않은 UI 위젯을 추가해야 하는 경우가 있다.
    예를 들어, 페이지에 지도 컴포넌트를 추가한다고 가정해 보면 여기에는 setZoomLevel() 메서드가 있으며, 확대/축소 수준을 React 코드의 zoomLevel state 변수와 동기화하고 싶다. Effect는 다음과 비슷할 것이다.
useEffect(() => {
  const map = mapRef.current;
  map.setZoomLevel(zoomLevel);
}, [zoomLevel]);
  • 이 경우 클린업이 필요하지 않다.
    개발 환경에서 React는 Effect를 두 번 호출하지만 동일한 값으로 setZoomLevel을 두 번 호출해도 아무 작업도 수행하지 않기 때문에 문제가 되지 않는다.
    약간 느릴 수는 있지만 상용 환경에서는 불필요하게 다시 마운트되지 않으므로 문제가 되지 않는다.
  • 일부 API는 연속으로 두 번 호출하는 것을 허용하지 않을 수 있다.
    예를 들어, 브라우저의 빌트인 요소인 <dialog>의 showModal 메서드는 두 번 호출하면 에러를 던잔다.
    클린업 함수를 구현하고 대화 상자를 닫도록 하자.
useEffect(() => {
  const dialog = dialogRef.current;
  dialog.showModal();
  return () => dialog.close();
}, []);
  • 개발 중에 Effect는 showModal()을 호출한 다음 즉시 close()를 호출하고, 다시 showModal()을 호출한다.
    이는 상용 환경에서 볼 수 있는 것처럼 showModal()을 한 번 호출하는 것과 체감상 동일하다.

4-2. 이벤트 구독하기

  • Effect가 무언가를 구독하는 경우, 클린업 함수는 구독을 취소해야한다.
useEffect(() => {
  function handleScroll(e) {
    console.log(window.scrollX, window.scrollY);
  }
  window.addEventListener('scroll', handleScroll);
  return () => window.removeEventListener('scroll', handleScroll);
}, []);
  • 개발 중에 Effect는 addEventListener()를 호출한 다음 즉시 removeEventListener()를 호출한다.
    그런 다음 동일한 핸들러를 사용하여 다시 addEventListener()를 사용함으로써, 한 번에 하나의 구독만 활성화 되도록 한다.
    는 상용 환경에서 addEventListener()를 한 번만 호출하는 것과 체감상 동일하다.

4-3. 트리거링 애니메이션

  • Effect가 무언가를 애니메이션하는 경우 클린업 함수는 애니메이션을 초기값으로 재설정해야한다.
useEffect(() => {
  const node = ref.current;
  node.style.opacity = 1; // Trigger the animation
                          // 애니메이션 촉발
  return () => {
    node.style.opacity = 0; // Reset to the initial value
                            // 초기값으로 재설정
  };
}, []);
  • 개발 과정에서 불투명도는 1이었다가, 0이었다가, 다시 1로 설정된다.
    이것은 상용 환경에서 1을 한 번만 설정하는 것과 체감상 동일하다.
    만약 트위닝을 지원하는 서드파티 애니메이션 라이브러리를 사용하는 경우라면, 클린업 함수에서 타임라인을 초기 state로 재설정해줘야 한다.

4-4. 데이터 페칭하기

  • Effect가 무언가를 페치하면 클린업 함수는 페치를 중단하거나 그 결과를 무시해야한다.
useEffect(() => {
  let ignore = false;

  async function startFetching() {
    const json = await fetchTodos(userId);
    if (!ignore) {
      setTodos(json);
    }
  }

  startFetching();

  return () => {
    ignore = true;
  };
}, [userId]);
  • 이미 발생한 네트워크 요청을 “실행 취소”할 수는 없으므로, 대신 클린업 함수에서 더 이상 관련이 없는 페치가 애플리케이션에 계속 영향을 미치지 않도록 해야힌다.
    만약 userId가 'Alice'에서 'Bob'으로 변경되면 클린업은 'Alice' 응답이 'Bob' 이후에 도착하더라도 이를 무시하도록 한다.
  • 개발 환경에서는 네트워크 탭에 두 개의 페치가 표시된다.
    위의 접근 방식을 사용하면 첫 번째 Effect가 즉시 정리되므로, ignore 변수의 복사본이 true로 설정된다.
    따라서 추가 요청이 있더라도 if (!ignore) 검사 덕분에 state에 영향을 미치지 않는다.
  • 상용 환경에서는 요청이 하나만 있다.
    발 중인 두 번째 요청이 귀찮은 경우 가장 좋은 방법은 요청을 중복 제거하고 컴포넌트 간에 응답을 캐시하는 솔루션을 사용하는 것이다.
function TodoList() {
  const todos = useSomeDataLibrary(`/api/user/${userId}/todos`);
  // ...
  • 이렇게 하면 개발 경험이 향상될 뿐만 아니라 애플리케이션이 더 빠르게 느껴진다.
    예를 들어, Back 버튼을 누르는 사용자는 일부 데이터가 캐시되기 때문에 다시 로드될 때까지 기다릴 필요가 없다.
    이러한 캐시는 직접 구축할 수도 있고, Effect에서 수동으로 페칭하는 기능을 대체하는 많은 대안 중 하나를 사용할 수도 있다.

4-5. 분석 전송

useEffect(() => {
  logVisit(url); // Sends a POST request
}, [url]);
  • 개발 환경에서는 모든 URL에 대해 logVisit이 두 번 호출되므로 이를 수정하고 싶을 수 있다.
    이전 예제와 마찬가지로 한 번 실행하는 것과 두 번 실행하는 것 사이에 사용자가 볼 수 있는 동작 차이는 없다.
    개발 머신의 로그가 상용 메트릭을 왜곡하는 것을 원하지는 않을 것이니, 실용적인 관점에서 개발 환경에서는 logVisit가 아무 것도 하지 않도록 하자.
    차피 개발 환경에서는 파일을 저장할 때마다 컴포넌트가 다시 마운트될 것이고, 따라서 추가 방문이 기록될 것이기 때문이다.
  • 상용 환경에서는 중복 방문 로그가 없다.
  • 전송하는 분석 이벤트를 디버깅하려면 앱을 스테이징 환경(상용 모드에서 실행됨)에 배포하거나, Strict Mode 및 개발 전용의 중복 마운트 검사를 일시적으로 해제할 수 있다.
    Effect 대신 경로 변경 이벤트 핸들러에서 분석을 전송할 수도 있다.
    보다 정확한 분석을 위해서는 intersection observers를 활용하면 뷰포트에 어떤 컴포넌트가 있고 얼마나 오래 표시되는지를 추적하는 데 도움이 될 수 있다.

4-6. Effect가 아님: 애플리케이션 초기화하기

  • 일부 로직은 애플리케이션이 시작될 때 한 번만 실행되어야 한다.
    이런 로직은 컴포넌트 외부에 넣을 수 있다.
if (typeof window !== 'undefined') { // Check if we're running in the browser.
                                     // 실행환경이 브라우저인지 여부 확인
  checkAuthToken();
  loadDataFromLocalStorage();
}

function App() {
  // ...
}
  • 이렇게 하면 위 로직은 브라우저가 페이지를 로드한 후 한 번만 실행된다.

4-7. Effect가 아님: 제품 구매하기

  • 클린업 함수를 작성하더라도 Effect를 두 번 실행함으로써 체감상 결과가 달라지는 것을 막을 방법이 없는 경우도 있다.
    예를 들어, Effect가 제품 구매와 같은 POST 요청을 보낸다고 하자.
useEffect(() => {
  // 🔴 Wrong: This Effect fires twice in development, exposing a problem in the code.
  // 🔴 틀렸습니다: 이 Effect는 개발모드에서 두 번 실행되며, 문제를 일으킵니다.
  fetch('/api/buy', { method: 'POST' });
}, []);
  • 제품을 두 번 사고 싶지는 않을 것이다. 이 로직을 Effect에 넣지 말아야 하는 이유이기도 하다.
    사용자가 다른 페이지로 이동한 다음 Back(뒤로가기)를 누르면, Effect가 다시 실행될 것이다.
    사용자는 페이지를 방문할 때 제품을 구매하고 싶지는 않을 것이다.
    구매 버튼을 클릭할 때 구매하길 원할 것이다.
  • 구매는 렌더링으로 인한 것이 아니다. 특정 상호 작용으로 인해 발생한다.
    사용자가 버튼을 누를 때만 실행되어야한다.
    Effect를 삭제하고 /api/buy 요청을 구매 버튼 이벤트 핸들러로 이동한다.
function handleClick() {
    // ✅ Buying is an event because it is caused by a particular interaction.
    // ✅ 구매는 특정 상호작용으로 인해 발생하므로 이벤트입니다.
    fetch('/api/buy', { method: 'POST' });
  }
  • 다시 마운트하면 애플리케이션의 로직이 깨지는 경우, 일반적으로 기존 버그를 발견할 수 있다.
    사용자 관점에서 페이지를 방문하는 것은 페이지를 방문하여 링크를 클릭하고 뒤로가기 버튼을 누르는 것과 다르지 않아야 한다.
    React는 개발 단계에서 컴포넌트를 다시 한 번 마운트하여 이 원칙을 준수하는지 확인한다.

5. 한 곳에 모으기

  • 이 플레이그라운드를 통해 실제로 Effect가 어떻게 작동하는지 “느껴볼” 수 있다.
  • 이 예에서는 setTimeout을 사용하여 Effect가 실행되고 3초 뒤에 input 텍스트가 포함된 콘솔 로그를 표시하도록 예약한다. 클린업 함수는 보류 중인 타임아웃을 취소합니다.
import { useState, useEffect } from 'react';

function Playground() {
  const [text, setText] = useState('a');

  useEffect(() => {
    function onTimeout() {
      console.log('⏰ ' + text);
    }

    console.log('🔵 Schedule "' + text + '" log');
    const timeoutId = setTimeout(onTimeout, 3000);

    return () => {
      console.log('🟡 Cancel "' + text + '" log');
      clearTimeout(timeoutId);
    };
  }, [text]);

  return (
    <>
      <label>
        What to log:{' '}
        <input
          value={text}
          onChange={e => setText(e.target.value)}
        />
      </label>
      <h1>{text}</h1>
    </>
  );
}

export default function App() {
  const [show, setShow] = useState(false);
  return (
    <>
      <button onClick={() => setShow(!show)}>
        {show ? 'Unmount' : 'Mount'} the component
      </button>
      {show && <hr />}
      {show && <Playground />}
    </>
  );
}
  • 처음에는 Schedule "a" log, Cancel "a" log, Schedule "a" log의 세 가지 로그가 표시된다. 3초 후에 a라는 로그도 표시된다.
    앞서 배운 것처럼 schedule/cancel 쌍이 한 번 더 출력되는 이유는 개발 환경에서 React가 클린업을 잘 구현했는지 확인하기 위해 컴포넌트를 다시 마운트하기 때문이다.
  • 이제 input을 편집하여 abc라고 입력하라.
    충분히 빨리 입력하면 Schedule "ab" log와 Cancel "ab" log, Schedule "abc" log가 바로 표시될 것이다.
    React는 항상 다음 렌더링의 Effect 전에 이전 렌더링의 Effect를 정리한다.
    따라서 입력을 빠르게 입력하더라도 한 번에 최대 한 번만 타임아웃이 예약된다.
  • input에 무언가를 입력한 다음 즉시 “Unmount the component”를 눌러보자.
    마운트를 해제하면 마지막 렌더링의 Effect가 어떻게 정리되는지 확인하자.
    여기서는 Effect가 실행 기회를 갖기 전에 마지막 타임아웃을 지운다.
  • 마지막으로 위의 컴포넌트를 편집하고 타임아웃이 취소되지 않도록 클린업 함수를 주석 처리 해보자.
    abcde를 빠르게 입력해 보자. 3초 후에 어떤 일이 일어날까?
  • 3초 후, 5개의 abcde가 아닌 일련의 (a, ab, abc, abcd, abcde)가 표시되어야 한다.
    각 Effect는 해당 렌더링에서 text 값을 “캡처”한다.
    text state가 변경되더라도, text = 'ab'인 렌더링의 Effect는 항상 'ab'를 표시한다.
    즉,각 렌더링의 Effect는 서로 분리되어 있다.
    이것이 어떻게 작동하는지 궁금하다면 클로저를 읽어 보자.

요약

  • 이벤트와 달리 Effect는 특정 상호 작용이 아닌 렌더링 자체에 의해 발생한다.
  • Effect를 사용하면 일부 외부 시스템(서드파티 API, 네트워크 등)과 컴포넌트를 동기화할 수 있다.
  • 기본적으로 Effect는 모든 렌더링 후에 실행된다.
    (초기 렌더링 포함)
  • React는 모든 의존성이 마지막 렌더링 시점과 동일한 값을 갖는 경우 Effect를 건너뛴다.
  • 의존성을 “선택”할 수는 없다.
    그들은 Effect 내부의 코드에 의해 결정된다.
  • 빈 의존성 배열([])은 컴포넌트 “마운팅”, 즉,화면에 추가되는 시점에 대응한다.
  • Strict 모드에서 React는 컴포넌트를 두 번 마운트하여(개발 중인 경우에만) Effect를 스트레스 테스트한다.
  • 다시 마운트를 수행함으로 인해 Effect가 깨지는 경우, 클린업 함수를 구현해야 한다.
    = React는 다음 Effect가 실행되기 전 및 마운트 해제 시점에 클린업 함수를 호출한다.

React 공식 문서

https://react.dev/

React 비공식 번역 문서

https://react-ko.dev/

MDN

https://developer.mozilla.org/ko/

Wikipedia

https://ko.wikipedia.org/wiki/

profile
Syoee
함께 일하고 싶어지는 동료, 프론트엔드 개발자입니다.
이전 포스트

React 공식문서 이해하기 (24)

다음 포스트

React 공식문서 이해하기 (26)

0개의 댓글