[6주차] 리액트 공식문서 한글 번역 : Lifecycle of Reactive Effects- 유동적인 Effect의 라이프사이클

[STUDY] 스터디/React Docs

[6주차] 리액트 공식문서 한글 번역 : Lifecycle of Reactive Effects- 유동적인 Effect의 라이프사이클

백루미 2023. 4. 5. 18:48

** 깃북을 닫았습니다

Escape Hatches : 유동적인 Effect의 라이프사이클(생명주기)

이펙트는 컴포넌트와 다른 라이프사이클을 가집니다. 컴포넌트는 마운트, 업데이트 또는 마운트 해제할 수 있습니다. 이펙트는 동기화를 시작하고 나중에 동기화를 중지하는 두 가지 작업만 할 수 있습니다. 이 사이클은 시간이 지남에 따라 변하는 props와 상태에 의존하는 Effect의 경우 여러 번 발생할 수 있습니다. React는 이펙트의 종속성을 올바르게 지정했는지 확인하는 린터 규칙을 제공합니다. 이렇게 하면 이펙트가 최신 props와 state에 동기화됩니다.

학습 내용

이펙트의 라이프사이클이 컴포넌트의 라이프사이클과 다른 점
각 이펙트를 개별적으로 생각하는 방법
이펙트를 다시 동기화해야 하는 시기와 그 이유
이펙트의 종속성이 결정되는 방법
값이 유동적이라는 것의 의미
빈 의존성 배열이 의미하는 것
React가 린터로 의존성이 올바른지 확인하는 방법
린터에 동의하지 않을 때 해야 할 일

Effect의 생명 주기

모든 React 컴포넌트는 동일한 라이프사이클을 거칩니다:

컴포넌트는 화면에 추가될 때 마운트됩니다.
컴포넌트는 보통 상호작용에 대한 응답으로 새로운 props나 state를 받으면 업데이트됩니다.
컴포넌트가 화면에서 제거되면 마운트 해제됩니다.

컴포넌트에 대해 생각하기에는 좋지만 Effect에 대해서는 생각하지 않는 것이 좋습니다. 대신 컴포넌트의 라이프사이클과 독립적으로 각 Effect를 생각해보세요. 이펙트는 외부 시스템을 현재 props 및 state와 동기화하는 방법을 설명합니다. 코드가 변경되면 동기화를 더 자주 또는 덜 자주 수행해야 합니다.

이 점을 설명하기 위해 컴포넌트를 채팅 서버에 연결하는 이펙트를 예로 들어보겠습니다:

const serverUrl = 'https://localhost:1234';

function ChatRoom({ roomId }) {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, [roomId]);
  // ...
}

Effect의 본문에는 동기화 시작 방법이 명시되어 있습니다:

    // ...
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
    // ...

Effect에서 반환되는 정리 함수는 동기화를 중지하는 방법을 지정합니다:

    // ...
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
    // ...

직관적으로 React는 컴포넌트가 마운트될 때 동기화를 시작하고 컴포넌트가 마운트 해제될 때 동기화를 중지할 것이라고 생각할 수 있습니다. 하지만 이것이 이야기의 끝이 아닙니다! 때로는 컴포넌트가 마운트된 상태에서 동기화를 여러 번 시작하고 중지해야 할 수도 있습니다.

왜 이런 일이 필요한지, 언제 발생하는지, 어떻게 이 동작을 제어할 수 있는지 살펴보겠습니다.

Note

일부 이펙트는 정리 함수를 전혀 반환하지 않습니다. 대부분의 경우 함수를 반환하고 싶겠지만, 그렇지 않은 경우 React는 빈 정리 함수를 반환한 것처럼 동작합니다.

동기화가 두 번 이상 수행되어야 하는 이유

이 ChatRoom 컴포넌트가 사용자가 드롭다운에서 선택한 roomId props를 받는다고 가정해 보겠습니다. 처음에 사용자가 "일반" 대화방을 roomId로 선택했다고 가정해 봅시다. 앱에 "일반" 채팅방이 표시됩니다:

const serverUrl = 'https://localhost:1234';

function ChatRoom({ roomId /* "general" */ }) {
  // ...
  return <h1>Welcome to the {roomId} room!</h1>;
}

UI가 표시되면 React가 Effect를 실행하여 동기화를 시작합니다. "일반" 방에 연결됩니다:

function ChatRoom({ roomId /* "general" */ }) {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId); // "general" 방에 연결
    connection.connect();
    return () => {
      connection.disconnect(); // "general" 방 연결해제
    };
  }, [roomId]);
  // ...

지금까지는 괜찮습니다.

나중에 사용자가 드롭다운에서 다른 방(예: "travel")을 선택합니다. 먼저 React가 UI를 업데이트합니다:

function ChatRoom({ roomId /* "travel" */ }) {
  // ...
  return <h1>Welcome to the {roomId} room!</h1>;
}

다음에 어떤 일이 일어날지 생각해 보세요. 사용자는 UI에서 "travel"이 선택된 대화방임을 알 수 있습니다. 그러나 지난번에 실행된 Effect는 여전히 "general" 대화방에 연결되어 있습니다. roomId 프로퍼티가 변경되었기 때문에 그때 Effect가 수행한 작업("general" 방에 연결)이 더 이상 UI와 일치하지 않습니다.

이 시점에서 React가 두 가지 작업을 수행하기를 원합니다:

이전 roomId와의 동기화를 중지합니다("general" 방에서 연결 끊기).
새 roomId와 동기화 시작("travel" 방에 연결)

다행히도, 여러분은 이미 이 두 가지를 수행하는 방법을 React에 가르쳤습니다! Effect의 본문에는 동기화를 시작하는 방법이 명시되어 있고, 정리 함수에는 동기화를 중지하는 방법이 명시되어 있습니다. 이제 React가 해야 할 일은 올바른 순서로 올바른 props와 상태로 호출하기만 하면 됩니다. 정확히 어떻게 일어나는지 살펴보겠습니다.

React가 이펙트를 재동기화하는 방법

ChatRoom 컴포넌트가 roomId props에 새로운 값을 받았다는 것을 기억하세요. 이전에는 "general"이었지만 이제는 "travel"입니다. 다른 방에 다시 연결하려면 React가 Effect를 다시 동기화해야 합니다.

동기화를 중지하기 위해 React는 "general" 방에 연결한 후 Effect가 반환한 정리 함수를 호출합니다. roomId가 "general"이었기 때문에, 정리 함수는 "general" 방에서 연결을 끊습니다:

function ChatRoom({ roomId /* "general" */ }) {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId); // Connects to the "general" room
    connection.connect();
    return () => {
      connection.disconnect(); // Disconnects from the "general" room
    };
    // ...

그러면 React는 이 렌더링 중에 여러분이 제공한 Effect를 실행합니다. 이번에는 roomId가 "travel"이므로 "travel" 채팅방과 동기화되기 시작합니다(결국 정리 함수도 호출될 때까지):

function ChatRoom({ roomId /* "travel" */ }) {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId); // Connects to the "travel" room
    connection.connect();
    // ...

덕분에 이제 사용자가 UI에서 선택한 방과 동일한 방에 연결됩니다. 재앙을 피했습니다!

컴포넌트가 다른 roomId로 다시 렌더링할 때마다 이펙트가 다시 동기화됩니다. 예를 들어 사용자가 roomId를 "travel"에서 "music"으로 변경한다고 가정해 봅시다. React는 다시 정리 함수를 호출하여 Effect 동기화를 중지합니다("travel" 방에서 연결을 끊습니다). 그런 다음 새 roomId 프로퍼티로 본문을 실행하여 동기화를 다시 시작합니다("music" 방에 연결).

마지막으로 사용자가 다른 화면으로 이동하면 ChatRoom이 마운트를 해제합니다. 이제 연결 상태를 유지할 필요가 전혀 없습니다. React는 마지막으로 Effect 동기화를 중지하고 "music" 채팅방에서 연결을 끊습니다.

Effect의 관점에서 생각하기

ChatRoom 컴포넌트의 관점에서 일어난 모든 일을 요약해 보겠습니다:

roomId가 "general"으로 설정된 ChatRoom이 마운트됨
roomId가 "travel"으로 설정되어 업데이트된 ChatRoom
roomId가 "music"으로 설정되어 업데이트된 ChatRoom
마운트 해제된 ChatRoom

컴포넌트의 라이프사이클에서 이러한 각 시점에서 Effect는 다른 작업을 수행했습니다:

Effect가 "general" 대화방에 연결됨
"general" 방에서 연결이 끊어지고 "travel" 방에 연결된 Effect
"travel" 룸에서 연결이 끊어지고 "music" 룸에 연결된 Effect
"music" 룸에서 연결이 끊어진 Effect

이제 Effect 자체의 관점에서 무슨 일이 일어났는지 생각해 봅시다:

 useEffect(() => {
    // roomId로 지정된 방에 연결된 Effect...
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      // ...연결이 끊어질 때까지
      connection.disconnect();
    };
  }, [roomId]);

이 코드의 구조를 보면 무슨 일이 일어났는지 겹치지 않는 시간의 시퀀스로 볼 수 있습니다:

"general" 방에 연결된 Effect(연결이 끊어질 때까지)
"travel" 방에 연결된 Effect(연결이 끊어질 때까지)
"음악" 방에 연결된 Effect (연결이 끊어질 때까지)

이전에는 컴포넌트의 관점에서 생각했습니다. 컴포넌트의 관점에서 보면 이펙트를 "렌더링 후" 또는 "마운트 해제 전"과 같은 특정 시점에 실행되는 "콜백" 또는 "생명주기 주기 이벤트"로 생각하기 쉽습니다. 이러한 사고 방식은 매우 빠르게 복잡해지므로 피하는 것이 가장 좋습니다.

대신 항상 한 번에 하나의 시작/중지 사이클에만 집중하세요. 컴포넌트가 마운트, 업데이트, 마운트 해제 중인지 여부는 중요하지 않아야 합니다. 동기화를 시작하는 방법과 동기화를 중지하는 방법만 설명하면 됩니다. 이 작업을 잘 수행하면 필요한 만큼 이펙트를 시작하고 중지할 수 있는 탄력성을 갖게 됩니다.

JSX를 생성하는 렌더링 로직을 작성할 때 컴포넌트가 마운트되는지 업데이트되는지 생각하지 않는 것을 떠올릴 수 있습니다. 화면에 무엇이 표시되어야 하는지 설명하면 나머지는 React가 알아서 처리합니다.

React가 이펙트를 다시 동기화할 수 있는지 확인하는 방법

다음은 여러분이 플레이할 수 있는 라이브 예시입니다. "채팅 열기"를 눌러 ChatRoom 컴포넌트를 마운트합니다:

import { useState, useEffect } from 'react';
import { createConnection } from './chat.js';

const serverUrl = 'https://localhost:1234';

function ChatRoom({ roomId }) {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => connection.disconnect();
  }, [roomId]);
  return <h1>Welcome to the {roomId} room!</h1>;
}

export default function App() {
  const [roomId, setRoomId] = useState('general');
  const [show, setShow] = useState(false);
  return (
    <>
      <label>
        Choose the chat room:{' '}
        <select
          value={roomId}
          onChange={e => setRoomId(e.target.value)}
        >
          <option value="general">general</option>
          <option value="travel">travel</option>
          <option value="music">music</option>
        </select>
      </label>
      <button onClick={() => setShow(!show)}>
        {show ? 'Close chat' : 'Open chat'}
      </button>
      {show && <hr />}
      {show && <ChatRoom roomId={roomId} />}
    </>
  );
}

컴포넌트가 처음 마운트될 때 3개의 로그가 표시됩니다: (개발환경에서 "먼저" 호출하는구나.. )

✅ https://localhost:1234... (개발 전용)에서 "general" 룸에 연결 중입니다.
❌ https://localhost:1234... "general" 방에서 연결 해제됨. (개발 전용)
✅ https://localhost:1234... 에서 "general" 방에 연결 중입니다.

처음 두 개의 로그는 개발 전용입니다. 개발 시 React는 항상 각 컴포넌트를 한 번씩 다시 마운트합니다.

React는 개발 단계에서 즉시 강제로 동기화하여 이펙트가 다시 동기화될 수 있는지 확인합니다. 이는 마치 문을 열었다가 닫을 때 도어락이 작동하는지 확인하기 위해 한 번 더 닫는 것과 비슷합니다. React는 개발 중에 Effect를 한 번 더 시작하고 중지하여 정리를 잘 구현했는지 확인합니다.

실제로 이펙트가 다시 동기화되는 주된 이유는 이펙트가 사용하는 일부 데이터가 변경된 경우입니다. 위의 샌드박스에서 선택한 채팅방을 변경해 보세요. roomId가 변경되면 Effect가 다시 동기화되는 것을 확인할 수 있습니다.

그러나 재동기화가 필요한 더 특이한 경우도 있습니다. 예를 들어, 채팅이 열려 있는 동안 위의 샌드박스에서 serverUrl을 편집해 보세요. 코드 편집에 대한 응답으로 이펙트가 어떻게 다시 동기화되는지 주목하세요. 앞으로 React는 재동기화에 의존하는 더 많은 기능을 추가할 수 있습니다.

React가 이펙트를 다시 동기화해야 한다는 것을 아는 방법

roomId가 변경된 후 Effect를 다시 동기화해야 한다는 것을 어떻게 React가 알았는지 궁금할 것입니다. 그것은 종속성 목록에 룸아이디를 포함시켜서 코드가 룸아이디에 종속되어 있음을 React에 알렸기 때문입니다:

function ChatRoom({ roomId }) { // roomId props는 시간이 지남에 따라 변경될 수 있습니다.
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId); // 이 이펙트는 roomId를 읽습니다. 
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, [roomId]); // React에게 이 Effect가 roomId를 "의존"한다고 알려줍니다.
  // ...

작동 방식은 다음과 같습니다:

roomId가 props이므로 시간이 지남에 따라 변경될 수 있다는 것을 알고 있습니다.
Effect가 roomId를 읽는다는 것을 알았습니다 (따라서 로직이 나중에 변경될 수 있는 값에 따라 달라집니다).
그렇기 때문에 룸아이디를 이펙트의 종속성으로 지정한 것입니다 (roomID 가 변경되면 다시 동기화되도록).

컴포넌트가 다시 렌더링될 때마다 React는 전달한 의존성 배열을 살펴봅니다. 배열의 값 중 하나라도 이전 렌더링 중에 전달한 동일한 지점의 값과 다르면 React는 Effect를 다시 동기화합니다.

예를 들어, 초기 렌더링 중에 ["general"]을 전달했는데 나중에 다음 렌더링 중에 ["travel"]을 전달한 경우, React는 "general"과 "travel"을 비교합니다. 이 값들은 (Object.is와 비교) 다른 값이기 때문에 React는 Effect를 다시 동기화합니다. 반면에 컴포넌트가 다시 렌더링되지만 roomId가 변경되지 않은 경우, Effect는 동일한 방에 연결된 상태로 유지됩니다.

각 효과는 별도의 동기화 프로세스를 나타냅니다.

이 로직은 이미 작성한 Effect와 동시에 실행되어야 하므로 관련 없는 로직을 Effect에만 추가하지 마세요. 예를 들어 사용자가 회의실을 방문할 때 분석 이벤트를 보내려고 한다고 가정해 보겠습니다. 이미 roomId에 의존하는 Effect가 있으므로 거기에 분석 호출을 추가하고 싶을 수 있습니다:

function ChatRoom({ roomId }) {
  useEffect(() => {
    logVisit(roomId);
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, [roomId]);
  // ...
}

하지만 나중에 이 Effect에 연결을 다시 설정해야 하는 다른 종속성을 추가한다고 가정해 보겠습니다. 이 Effect가 다시 동기화되면 의도하지 않은 동일한 방에 대해 logVisit(roomId)도 호출합니다. 방문을 기록하는 것은 연결과는 별개의 프로세스입니다. 두 개의 개별 Effect 작성하세요:

function ChatRoom({ roomId }) {
  useEffect(() => {
    logVisit(roomId);
  }, [roomId]);

  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    // ...
  }, [roomId]);
  // ...
}

코드의 각 Effect는 별도의 독립적인 동기화 프로세스를 나타내야 합니다.

위의 예시에서는 한 효과를 삭제해도 다른 효과의 로직이 깨지지 않습니다. 이는 서로 다른 것을 동기화하므로 분할하는 것이 합리적이라는 것을 잘 보여줍니다. 반면에 일관된 로직을 별도의 Effect로 분리하면 코드가 "더 깔끔해" 보일 수 있지만 유지 관리가 더 어려워집니다. 따라서 코드가 더 깔끔해 보이는지 여부가 아니라 프로세스가 동일하거나 분리되어 있는지를 고려해야 합니다.

유동적인 값에 "반응"하는 Effect

Effect가 두 개의 변수(serverUrl 및 roomId)를 읽지만 종속성으로 roomId만 지정했습니다:

const serverUrl = 'https://localhost:1234';

function ChatRoom({ roomId }) {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, [roomId]);
  // ...
}

serverUrl이 종속성이 될 필요가 없는 이유는 무엇인가요?

서버Url은 리렌더링으로 인해 변경되지 않기 때문입니다. 컴포넌트가 몇 번이나 다시 렌더링하든, 그 이유와 상관없이 항상 동일합니다. serverUrl은 절대 변경되지 않으므로 종속성으로 지정하는 것이 합리적이지 않습니다. 결국 종속성은 시간이 지남에 따라 변경될 때만 무언가를 수행합니다!

반면에 roomId는 다시 렌더링할 때 달라질 수 있습니다. 컴포넌트 내부에서 선언된 props, state 및 기타 값은 렌더링 중에 계산되고 React 데이터 흐름에 참여하기 때문에 유동적입니다.

serverUrl이 상태 변수라면 유동적일 것입니다. 유동적인 값은 의존성에 포함되어야 합니다:

function ChatRoom({ roomId }) { // Props는 변할 수 있다.
  const [serverUrl, setServerUrl] = useState('https://localhost:1234'); // State는 바뀔 수도 있다.

  useEffect(() => {
    const connection = createConnection(serverUrl, roomId); // Effect는 props 와 state를 참조한다
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, [roomId, serverUrl]); // 따라서 이 Effect가 props 와 state를 의존하고있다고 알려줘야한다.
  // ...
}

서버 URL을 종속성으로 포함하면 이펙트가 변경된 후 다시 동기화되도록 할 수 있습니다.

이 샌드박스에서 선택한 대화방을 변경하거나 서버 URL을 수정해 보세요:

import { useState, useEffect } from 'react';
import { createConnection } from './chat.js';

function ChatRoom({ roomId }) {
  const [serverUrl, setServerUrl] = useState('https://localhost:1234');

  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => connection.disconnect();
  }, [roomId, serverUrl]);

  return (
    <>
      <label>
        Server URL:{' '}
        <input
          value={serverUrl}
          onChange={e => setServerUrl(e.target.value)}
        />
      </label>
      <h1>Welcome to the {roomId} room!</h1>
    </>
  );
}

export default function App() {
  const [roomId, setRoomId] = useState('general');
  return (
    <>
      <label>
        Choose the chat room:{' '}
        <select
          value={roomId}
          onChange={e => setRoomId(e.target.value)}
        >
          <option value="general">general</option>
          <option value="travel">travel</option>
          <option value="music">music</option>
        </select>
      </label>
      <hr />
      <ChatRoom roomId={roomId} />
    </>
  );
}

roomId 또는 serverUrl과 같은 반응형 값을 변경할 때마다 Effect가 채팅 서버에 다시 연결됩니다.

의존성이 비어있는 Effect의 의미

serverUrl과 roomId를 컴포넌트 외부로 이동하면 어떻게 될까요?

const serverUrl = 'https://localhost:1234';
const roomId = 'general';

function ChatRoom() {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, []); // ✅ 선언된 모든 종속성
  // ...
}

이제 Effect의 코드에는 유동적인 값이 사용되지 않으므로 종속성이 비어있을 수 있습니다([]).

컴포넌트의 관점에서 생각해보면, 빈 [] 종속성 배열은 이 Effect가 컴포넌트가 마운트될 때만 채팅방에 연결되고 컴포넌트가 마운트 해제될 때만 연결이 끊어진다는 것을 의미합니다. (React는 로직을 스트레스 테스트하기 위해 개발 단계에서 한 번 더 동기화한다는 점을 기억하세요).

import { useState, useEffect } from 'react';
import { createConnection } from './chat.js';

const serverUrl = 'https://localhost:1234';
const roomId = 'general';

function ChatRoom() {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => connection.disconnect();
  }, []);
  return <h1>Welcome to the {roomId} room!</h1>;
}

export default function App() {
  const [show, setShow] = useState(false);
  return (
    <>
      <button onClick={() => setShow(!show)}>
        {show ? 'Close chat' : 'Open chat'}
      </button>
      {show && <hr />}
      {show && <ChatRoom />}
    </>
  );
}

하지만 이펙트의 관점에서 생각하면 마운트 및 마운트 해제에 대해 전혀 생각할 필요가 없습니다. 중요한 것은 이펙트가 동기화를 시작하고 중지하는 작업을 지정한 것입니다. 현재는 유동적인 종속성이 없습니다. 하지만 사용자가 시간이 지남에 따라 roomId 또는 serverUrl을 변경하려는 경우(그리고 유동적인 값이 되는 경우) Effect의 코드는 변경되지 않습니다. 종속성에 추가하기만 하면 됩니다.

컴포넌트 본문에서 선언된 모든 변수는 유동적이다.

props와 state만 유동값인 것은 아닙니다. 이들로부터 계산하는 값도 유동적인 값입니다. props나 state가 변경되면 컴포넌트가 다시 렌더링되고 그로부터 계산된 값도 변경됩니다. 그렇기 때문에 이펙트가 사용하는 컴포넌트 본문의 모든 변수는 이펙트 종속성 목록에 있어야 합니다.

사용자가 드롭다운에서 채팅 서버를 선택할 수 있지만 설정에서 기본 서버를 구성할 수도 있다고 가정해 봅시다. 이미 설정 상태를 컨텍스트에 넣어서 해당 컨텍스트에서 설정을 읽었다고 가정해 보겠습니다. 이제 prop에서 선택한 서버와 기본 서버를 기준으로 serverUrl을 계산합니다:

function ChatRoom({ roomId, selectedServerUrl }) { // roomId 는 유동값
  const settings = useContext(SettingsContext); // settings 는 유동값
  const serverUrl = selectedServerUrl ?? settings.defaultServerUrl; // serverUrl 는 유동값
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId); // Effect는 roomId 와 serverUrl을 참조함
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, [roomId, serverUrl]); // 따라서 둘 중 하나가 변경되면 다시 동기화해야 합니다!
  // ...
}

이 예제에서 serverUrl은 props나 state 가 아닙니다. 렌더링 중에 계산하는 일반 변수입니다. 하지만 렌더링 중에 계산되므로 재렌더링으로 인해 변경될 수 있습니다. 이것이 바로 유동값인 이유입니다.

컴포넌트 내부의 모든 값(컴포넌트 본문의 prop, state, 변수)은 유동값입니다. 모든 유동값은 리렌더링에서 변경될 수 있으므로 유동값을 Effect의 종속 요소로 포함시켜야 합니다.

즉, Effect는 컴포넌트 본문의 모든 값에 "반응"합니다.

Deep Dive - 전역 또는 변경 가능한 값이 종속성이 될 수 있나요?

변경 가능한 값(전역 변수 포함)은 반응하지 않습니다.

location.pathname과 같은 변경 가능한 값은 의존성이 될 수 없습니다. 이 값은 변경 가능하기 때문에 React 렌더링 데이터 흐름 외부에서 언제든지 변경할 수 있습니다. 이 값을 변경해도 컴포넌트가 다시 렌더링되지는 않습니다. 따라서 종속성에서 지정했더라도 React는 이펙트가 변경될 때 이펙트를 다시 동기화할지 알 수 없습니다. 또한 렌더링 도중(의존성을 계산할 때) 변경 가능한 데이터를 읽는 것은 렌더링의 순수성을 깨뜨리기 때문에 React의 규칙을 위반합니다. 대신, useSyncExternalStore로 외부 변경 가능한 값을 읽고 구독해야 합니다.

ref.current와 같은 변경 가능한 값이나 이 값에서 읽은 것 역시 종속성이 될 수 없습니다. useRef가 반환하는 ref 객체 자체는 종속성이 될 수 있지만 current 프로퍼티는 의도적으로 변경 가능합니다. 이를 통해 재렌더링을 트리거하지 않고도 무언가를 추적할 수 있습니다. 하지만 변경해도 다시 렌더링이 트리거되지 않기 때문에 유동적인 값이 아니며, React는 이 값이 변경될 때 Effect를 다시 실행할지 알지 못합니다.

이 페이지의 아래에서 배우게 되겠지만, 린터는 이러한 문제를 자동으로 검사합니다.

React는 모든 유동값을 의존성으로 지정했는지 확인합니다.

린터가 React에 대해 구성된 경우, Effect의 코드에서 사용되는 모든 유동값이 해당 종속성으로 선언되었는지 확인합니다. 예를 들어, roomId와 serverUrl이 모두 유동값이기 때문에 이것은 린트 오류입니다:

import { useState, useEffect } from 'react';
import { createConnection } from './chat.js';

function ChatRoom({ roomId }) { // roomId is reactive
  const [serverUrl, setServerUrl] = useState('https://localhost:1234'); // serverUrl 는 유동값

  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => connection.disconnect();
  }, []); // <-- 여기 뭔가 잘못되었음

  return (
    <>
      <label>
        Server URL:{' '}
        <input
          value={serverUrl}
          onChange={e => setServerUrl(e.target.value)}
        />
      </label>
      <h1>Welcome to the {roomId} room!</h1>
    </>
  );
}

export default function App() {
  const [roomId, setRoomId] = useState('general');
  return (
    <>
      <label>
        Choose the chat room:{' '}
        <select
          value={roomId}
          onChange={e => setRoomId(e.target.value)}
        >
          <option value="general">general</option>
          <option value="travel">travel</option>
          <option value="music">music</option>
        </select>
      </label>
      <hr />
      <ChatRoom roomId={roomId} />
    </>
  );
}

이것은 React 오류처럼 보일 수 있지만 실제로는 코드의 버그를 지적하는 것입니다. roomId와 serverUrl은 시간이 지남에 따라 변경될 수 있지만, 변경 시 Effect를 다시 동기화하는 것을 잊어버리고 있습니다. 사용자가 UI에서 다른 값을 선택한 후에도 초기 roomId 및 serverUrl에 계속 연결됩니다.

이 버그를 수정하려면 린터의 제안에 따라 이펙트의 종속 요소로 roomId와 serverUrl을 지정하세요:

function ChatRoom({ roomId }) { // roomId is reactive
  const [serverUrl, setServerUrl] = useState('https://localhost:1234'); // serverUrl 는 유동값
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, [serverUrl, roomId]); // ✅ 모든 종속성이 선언됨
  // ...
}

위의 샌드박스에서 이 수정 방법을 시도해 보세요. 지연 오류가 사라지고 필요할 때 채팅이 다시 연결되는지 확인합니다.

Note

어떤 경우에는 컴포넌트 내부에서 값이 선언되더라도 절대 변하지 않는다는 것을 React가 알고 있습니다. 예를 들어, useState에서 반환되는 set 함수와 useRef에서 반환되는 ref 객체는 안정적이며, 다시 렌더링해도 변경되지 않도록 보장됩니다. 안정된 값은 반응하지 않으므로 목록에서 생략할 수 있습니다. 이러한 값은 변경되지 않으므로 포함해도 상관없습니다.

다시 동기화하지 않으려는 경우 수행 방법

이전 예제에서는 roomId와 serverUrl을 종속성으로 나열하여 린트 오류를 수정했습니다.

그러나 대신 이러한 값이 유동값이 아니라는 것, 즉 재렌더링의 결과로 변경될 수 없다는 것을 린트에 '증명'할 수 있습니다. 예를 들어 serverUrl과 roomId가 렌더링에 의존하지 않고 항상 같은 값을 갖는다면 컴포넌트 외부로 옮길 수 있습니다. 이제 종속성이 될 필요가 없습니다:

const serverUrl = 'https://localhost:1234'; // serverUrl 은 유동적이지 않음
const roomId = 'general'; // roomId 은 유동적이지 않음

function ChatRoom() {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, []); // ✅ 모든 의존값이 선언됨
  // ...
}

이펙트 내부로 이동할 수도 있습니다. 렌더링 중에 계산되지 않으므로 반응하지 않습니다:

function ChatRoom() {
  useEffect(() => {
    const serverUrl = 'https://localhost:1234'; // serverUrl 은 유동값이 아님
    const roomId = 'general'; // roomId 은 유동값이 아님
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, []); // ✅ 모든 종속성이 선언됨
  // ...
}

이펙트는 유동적인 코드 블록입니다. 내부에서 읽은 값이 변경되면 다시 동기화됩니다. 상호작용당 한 번만 실행되는 이벤트 핸들러와 달리 이펙트는 동기화가 필요할 때마다 실행됩니다.

종속성을 "선택"할 수 없습니다. 종속성에는 이펙트에서 읽은 모든 유동값이 포함되어야 합니다. 린터가 이를 강제합니다. 때때로 이로 인해 무한 루프와 같은 문제가 발생하거나 이펙트가 너무 자주 다시 동기화될 수 있습니다. 린터를 억제하여 이러한 문제를 해결하지 마세요! 대신 시도해 볼 수 있는 방법은 다음과 같습니다:

이펙트가 독립적인 동기화 프로세스를 나타내는지 확인하세요. 이펙트가 아무것도 동기화하지 않는다면 불필요한 것일 수 있습니다. 여러 개의 독립적인 것을 동기화하는 경우 분할하세요.
prop이나 state에 "반응"하지 않고 이펙트를 다시 동기화하지 않고 최신 값을 읽으려면 이펙트를 반응하는 부분(이펙트에 유지)과 반응하지 않는 부분(이펙트 이벤트라고 하는 것으로 추출)으로 분리하면 됩니다. 이벤트와 이펙트 분리에 대해 읽어보세요.
객체와 함수를 종속성으로 의존하지 마세요. 렌더링 중에 객체와 함수를 생성한 다음 Effect에서 읽으면 렌더링할 때마다 객체와 함수가 달라집니다. 그러면 매번 이펙트를 다시 동기화해야 합니다. Effect에서 불필요한 종속성 제거에 대해 자세히 읽어보세요.

함정

린터는 여러분의 친구이지만 그 힘은 제한되어 있습니다. 린터는 종속성이 잘못되었을 때만 알 수 있습니다. 각 사례를 해결하는 최선의 방법은 알지 못합니다. 만약 린터가 종속성을 제안하지만 이를 추가하면 루프가 발생한다고 해서 링터를 무시해야 한다는 의미는 아닙니다. 해당 값이 반응적이지 않고 종속성이 될 필요가 없도록 Effect 내부(또는 외부)의 코드를 변경해야 합니다.

기존 코드베이스가 있는 경우 이와 같이 린터를 억제하는 이펙트가 있을 수 있습니다:

useEffect(() => {
  // ...
  // 🔴 이런 식으로 린터를 제한하지 마세요:
  // eslint-ignore-next-line react-hooks/exhaustive-deps
}, []);

다음 페이지에서는 규칙을 위반하지 않고 이 코드를 수정하는 방법을 알아보세요. 언제나 고칠 가치가 있습니다!

요약

컴포넌트는 마운트, 업데이트, 마운트 해제할 수 있습니다.
각 Effect는 주변 컴포넌트와 별도의 라이프사이클을 가집니다.
각 Effect는 시작 및 중지할 수 있는 별도의 동기화 프로세스를 설명합니다.
Effect를 작성하고 읽을 때는 컴포넌트의 관점(마운트, 업데이트 또는 마운트 해제 방법)이 아닌 각 개별 효과의 관점(동기화 시작 및 중지 방법)에서 생각하세요.
컴포넌트 본문 내부에 선언된 값은 "유동적인"입니다.
유동값은 시간이 지남에 따라 변경될 수 있으므로 이펙트를 다시 동기화해야 합니다.
린터는 이펙트 내부에서 사용된 모든 유동값이 종속성으로 지정되었는지 확인합니다.
린터에 의해 플래그가 지정된 모든 오류는 합법적인 오류입니다. 규칙을 위반하지 않도록 코드를 수정할 수 있는 방법은 항상 있습니다.

과제 1/5: 모든 키 입력 시 재연결 문제 해결

이 예제에서는 ChatRoom 컴포넌트가 마운트될 때 채팅방에 연결되고, 마운트가 해제될 때 연결이 끊어지며, 다른 채팅방을 선택하면 다시 연결됩니다. 이 동작은 올바르므로 계속 작동해야 합니다.

하지만 문제가 있습니다. 하단의 메시지 상자 입력란에 입력할 때마다 ChatRoom도 채팅에 다시 연결됩니다. (콘솔을 지우고 입력란에 입력하면 이 문제를 확인할 수 있습니다.) 이런 일이 발생하지 않도록 문제를 해결하세요.

https://codesandbox.io/s/fix-reconnecting-on-every-keystroke-dsbqgg?file=/App.js

과제 2/5: 동기화 켜고 끄기

이 예제에서는 Effect가 창 포인터 이동 이벤트를 구독하여 화면에서 분홍색 점을 이동합니다. 미리 보기 영역 위로 마우스를 가져가거나(모바일 디바이스의 경우 화면을 터치) 분홍색 점이 사용자의 움직임을 어떻게 따라가는지 확인해 보세요.

확인란도 있습니다. 확인란을 선택하면 canMove 상태 변수가 토글되지만 이 상태 변수는 코드의 어느 곳에서도 사용되지 않습니다. 여러분의 임무는 canMove가 거짓일 때(확인란이 선택되어 있을 때) 점의 움직임이 멈추도록 코드를 변경하는 것입니다. 확인란을 다시 켜고 canMove를 true로 설정하면 상자가 다시 움직여야 합니다. 즉, 도트가 움직일 수 있는지 여부는 확인란의 체크 여부와 동기화 상태를 유지해야 합니다.

https://codesandbox.io/s/switch-synchronization-on-and-off-ynhhr6?file=/App.js

과제 3/5: 오래된 값 버그 조사하기

이 예제에서는 체크박스가 켜져 있을 때 분홍색 점이 움직여야 하고 체크박스가 꺼져 있을 때는 움직임을 멈춰야 합니다. 이를 위한 로직은 이미 구현되어 있습니다. handleMove 이벤트 핸들러가 canMove 상태 변수를 확인합니다.

그러나 어떤 이유에서인지 handleMove 내부의 canMove 상태 변수는 체크박스를 체크한 후에도 항상 참인 "부실" 상태인 것처럼 보입니다. 어떻게 이런 일이 가능할까요? 코드에서 실수를 찾아서 수정하세요.

https://codesandbox.io/s/investigate-a-stale-value-bug-44m2er?file=/App.js

과제 4/5: 연결 스위치 수정

이 예제에서 chat.js의 채팅 서비스는 createEncryptedConnection과 createUnencryptedConnection이라는 두 개의 서로 다른 API를 노출합니다. 루트 App 컴포넌트는 사용자가 암호화 사용 여부를 선택할 수 있도록 한 다음, 해당 API 메서드를 하위 ChatRoom 컴포넌트에 createConnection를 props로 전달합니다.

처음에는 콘솔 로그에 연결이 암호화되지 않았다고 표시됩니다. 확인란을 켜면 아무 일도 일어나지 않습니다. 그러나 그 후에 선택한 대화방을 변경하면 채팅이 다시 연결되고 콘솔 메시지에서 볼 수 있듯이 암호화가 활성화됩니다. 이것은 버그입니다. 확인란을 토글해도 채팅이 다시 연결되도록 버그를 수정하세요.

https://codesandbox.io/s/fix-a-connection-switch-ispms3?file=/ChatRoom.js

과제 5/5: 셀렉트박스 체인 채우기

이 예제에는 두 개의 셀렉트박스가 있습니다. 하나의 셀렉트박스에서 사용자는 행성을 선택할 수 있습니다. 다른 셀렉트박스는 사용자가 해당 행성의 장소를 선택할 수 있도록 합니다. 두 번째 박스는 아직 작동하지 않습니다. 여러분의 임무는 선택한 행성의 장소를 표시하도록 만드는 것입니다.

첫 번째 셀렉트박스의 작동 방식을 살펴보겠습니다. 이 상자는 "/planets" API 호출의 결과로 planetList 상태를 채웁니다. 현재 선택된 행성의 ID는 planetId 상태 변수에 보관됩니다. placeList 상태 변수가 "/planets/" + planetId + "/places" API 호출의 결과로 채워지도록 몇 가지 추가 코드를 추가할 위치를 찾아야 합니다.

이 코드를 올바르게 구현하면 행성을 선택하면 장소 목록이 채워져야 합니다. 행성을 변경하면 장소 목록이 변경되어야 합니다.

https://codesandbox.io/s/populate-a-chain-of-select-boxes-ucgdr9?file=/App.js

발표요약)

1. 유동적인 값 (=변경될수있는 값), props나 state, 컴포넌트 내부에 선언된 변수값은 의존성 배열에 추가해준다. 그래야 Effect가 동기화를 제대로 할수있다. (Effect가 사용하는 컴포넌트 내부에선언된 모든값은 유동값이다)

2. 린터가 의존성배열에 문제가 있음을 알려주면 반드시 코드를 수정하자. 린터제한 하지말고 코드를 수정하자.

3. location.pathname이나 ref.current 같은.. 외부에서 변경 가능한 값은 의존성배열에 추가하지않는다. 이와 같은 값은 React 렌더링 데이터 흐름 외부에서 언제든지 변경할 수 있다. 렌더링 도중(의존성을 계산할 때) 변경 가능한 데이터를 읽는 것은 렌더링의 순수성을 깨뜨리기 때문에 React의 규칙을 위반한다.

저작자표시 비영리 변경금지

'[STUDY] 스터디 > React Docs' 카테고리의 다른 글

[7주차] 리액트 공식문서 한글 번역 : Removing Effect Dependencies - 이펙트 종속성 제거하기 (0)	2023.04.07
[6주차] 리액트 공식문서 한글 번역 : Separating Events from Effects - 이벤트와 Effect 분리하기 (0)	2023.04.07
[6주차] 리액트 공식문서 한글 번역 : You Might Not Need an Effect- Effect는 필요 없을수도 있다 (0)	2023.04.04
[6주차] 리액트 공식문서 한글 번역 : Synchronizing with Effects - Effects와 동기화하기 (0)	2023.03.26
[5주차] React docs 한글 번역 : Manipulating the DOM with Refs - Refs로 DOM 조작하기 (0)	2023.03.18

Home

현재글[6주차] 리액트 공식문서 한글 번역 : Lifecycle of Reactive Effects- 유동적인 Effect의 라이프사이클

스페이스 루미