Component

class Greeting extends Component {
  render() {
    return <h1>Hello, {this.props.name}!</h1>;
  }
}

• Reference참조
  • Component
  • context
  • props
  • refs
  • state
  • constructor(props)
  • componentDidCatch(error, info)
  • componentDidMount()
  • componentDidUpdate(prevProps, prevState, snapshot?)
  • componentWillMount()
  • componentWillReceiveProps(nextProps)
  • componentWillUpdate(nextProps, nextState)
  • componentWillUnmount()
  • forceUpdate(callback?)
  • getChildContext()
  • getSnapshotBeforeUpdate(prevProps, prevState)
  • render()
  • setState(nextState, callback?)
  • shouldComponentUpdate(nextProps, nextState, nextContext)
  • UNSAFE_componentWillMount()
  • UNSAFE_componentWillReceiveProps(nextProps, nextContext)
  • UNSAFE_componentWillUpdate(nextProps, nextState)
  • static childContextTypes
  • static contextTypes
  • static contextType
  • static defaultProps
  • static propTypes
  • static getDerivedStateFromError(error)
  • static getDerivedStateFromProps(props, state)
• Usage사용법
  • Defining a class component클래스 컴포넌트 정의하기
  • Adding state to a class component클래스 컴포넌트에 state 추가하기
  • Adding lifecycle methods to a class component클래스 컴포넌트에 생명주기 메서드 추가하기
  • Catching rendering errors with an error boundary에러 경계로 렌더링 오류 포착하기
• Alternatives대안
  • Migrating a simple component from a class to a function클래스에서 함수로 간단한 컴포넌트 마이그레이션하기
  • Migrating a component with state from a class to a function클래스에서 함수로 state가 있는 컴포넌트 마이그레이션하기
  • Migrating a component with lifecycle methods from a class to a function생명주기 메서드가 있는 컴포넌트를 클래스에서 함수로 마이그레이션하기
  • Migrating a component with context from a class to a function컨텍스트가 있는 컴포넌트를 클래스에서 함수로 마이그레이션하기

Reference참조

Component

To define a React component as a class, extend the built-in Component class and define a render method: React 컴포넌트를 클래스로 정의하려면 빌트인 Component 클래스를 확장하고 render 메서드를 정의하세요.

import { Component } from 'react';

class Greeting extends Component {
  render() {
    return <h1>Hello, {this.props.name}!</h1>;
  }
}

Only the render method is required, other methods are optional. 오직 render 메서드만 필수이며, 그밖의 메서드들은 선택사항입니다.

See more examples below. 아래에서 더 많은 예시를 확인하세요.

context

The context of a class component is available as this.context. It is only available if you specify which context you want to receive using static contextType (modern) or static contextTypes (deprecated). 클래스 컴포넌트의 컨텍스트는 this.context 로 사용가능합니다. static contextType(최신) 또는 static contextTypes(지원 중단)을 사용하여 어떤 컨테스트를 수신하고자 하는지를 지정하는 경우에만 사용할 수 있습니다 .

A class component can only read one context at a time. 클래스 컴포넌트는 한 번에 하나의 컨텍스트만 읽을 수 있습니다.

class Button extends Component {
  static contextType = ThemeContext;

  render() {
    const theme = this.context;
    const className = 'button-' + theme;
    return (
      <button className={className}>
        {this.props.children}
      </button>
    );
  }
}

props

The props passed to a class component are available as this.props. 클래스 컴포넌트에 전달된 props는 this.props로 사용합니다.

class Greeting extends Component {
  render() {
    return <h1>Hello, {this.props.name}!</h1>;
  }
}

<Greeting name="Taylor" />

refs

Lets you access legacy string refs for this component. 이 컴포넌트에 대한 legacy 문자열 refs에 접근할 수 있습니다.

state

The state of a class component is available as this.state. The state field must be an object. Do not mutate the state directly. If you wish to change the state, call setState with the new state. 클래스 컴포넌트의 state는 this.state로 사용할 수 있습니다. state 필드는 객체여야 합니다. state를 직접 변경하지 마세요. state를 변경하려면 새로운 state로 setState를 호출하세요.

class Counter extends Component {
  state = {
    age: 42,
  };

  handleAgeChange = () => {
    this.setState({
      age: this.state.age + 1 
    });
  };

  render() {
    return (
      <>
        <button onClick={this.handleAgeChange}>
        Increment age
        </button>
        <p>You are {this.state.age}.</p>
      </>
    );
  }
}

constructor(props)

The constructor runs before your class component mounts (gets added to the screen). Typically, a constructor is only used for two purposes in React. It lets you declare state and bind your class methods to the class instance: constructor는 클래스 컴포넌트가 마운트되기 전에 실행됩니다(화면에 추가됩니다). 일반적으로 constructor는 React에서 다음 두 가지 용도로만 사용합니다. state를 선언하고, 클래스 메서드를 클래스 인스턴스에 바인딩할 수 있습니다:

class Counter extends Component {
  constructor(props) {
    super(props);
    this.state = { counter: 0 };
    this.handleClick = this.handleClick.bind(this);
  }

  handleClick() {
    // ...
  }

If you use modern JavaScript syntax, constructors are rarely needed. Instead, you can rewrite this code above using the public class field syntax which is supported both by modern browsers and tools like Babel: 최신 JavaScript 구문을 사용하는 경우 constructor가 거의 필요하지 않습니다. 대신 최신 브라우저와 Babel과 같은 도구에서 모두 지원되는 공용 클래스 필드 구문을 사용하여 위의 코드를 다시 작성할 수 있습니다:

class Counter extends Component {
  state = { counter: 0 };

  handleClick = () => {
    // ...
  }

A constructor should not contain any side effects or subscriptions. constructor에는 사이드 이펙트나 구독이 포함되어서는 안 됩니다.

Parameters매개변수

• props: The component’s initial props.
  props : 컴포넌트의 초기 props입니다.

Returns반환값

constructor should not return anything. constructor는 아무 것도 반환하지 않아야 합니다.

Caveats주의사항

• Do not run any side effects or subscriptions in the constructor. Instead, use componentDidMount for that. constructor에서 사이드 이펙트나 구독을 실행하지 마세요. 대신 componentDidMount 를 사용하세요

• Inside a constructor, you need to call super(props) before any other statement. If you don’t do that, this.props will be undefined while the constructor runs, which can be confusing and cause bugs. constructor 내부에서는 다른 구문보다 먼저 super(props)를 호출해야 합니다. 그렇게 하지 않으면 constructor가 실행되는 동안 this.props가 undefined가 되어 혼란스럽게 하고 버그를 야기할 수 있습니다.

• Constructor is the only place where you can assign this.state directly. In all other methods, you need to use this.setState() instead. Do not call setState in the constructor. this.state를 직접 할당할 수 있는 곳은 constructor뿐입니다. 다른 모든 메서드에서는 this.setState()를 대신 사용해야 합니다. constructor 내부에서 setState를 호출하지 마세요.

• When you use server rendering, the constructor will run on the server too, followed by the render method. However, lifecycle methods like componentDidMount or componentWillUnmount will not run on the server. 서버 렌더링을 사용하는 경우 constructor도 서버에서 실행되고 render 메서드가 이어서 실행됩니다. 그러나 componentDidMount 또는 componentWillUnmount와 같은 생명주기 메서드는 서버에서 실행되지 않습니다.

• When Strict Mode is on, React will call constructor twice in development and then throw away one of the instances. This helps you notice the accidental side effects that need to be moved out of the constructor. Strict Mode가 켜져 있으면 React는 개발 과정에서 constructor를 두 번 호출한 다음 인스턴스 중 하나를 버립니다. 이렇게 하면 constructor에서 실수로 발생한 사이드 이펙트을 발견하여 제거하는 데 도움이 됩니다.

componentDidCatch(error, info)

If you define componentDidCatch, React will call it when some child component (including distant children) throws an error during rendering. This lets you log that error to an error reporting service in production. componentDidCatch를 정의하면 렌더링 도중 일부 자식 컴포넌트(멀리 떨어진 자식 포함)가 오류를 발생시킬 때 React가 이를 호출합니다. 이를 통해 상용 환경의 오류 보고 서비스에 해당 오류를 기록할 수 있습니다.

Typically, it is used together with static getDerivedStateFromError which lets you update state in response to an error and display an error message to the user. A component with these methods is called an error boundary. 일반적으로 이 메서드는 에러에 대한 응답으로 state를 업데이트하고 사용자에게 에러 메시지를 표시할 수 있는 static getDerivedStateFromError와 함께 사용됩니다. 이러한 메서드가 있는 컴포넌트를 error boundary라고 합니다.

See an example. 예시를 확인하세요.

Parameters매개변수

• error: The error that was thrown. In practice, it will usually be an instance of Error but this is not guaranteed because JavaScript allows to throw any value, including strings or even null. error: 발생한 에러입니다. 일반적으로 Error의 인스턴스가 되지만, JavaScript에서는 문자열이나 null을 포함한 모든 값을 throw 할 수 있으므로, 실제로는 반드시 보장되지는 않습니다.

• info: An object containing additional information about the error. Its componentStack field contains a stack trace with the component that threw, as well as the names and source locations of all its parent components. In production, the component names will be minified. If you set up production error reporting, you can decode the component stack using sourcemaps the same way as you would do for regular JavaScript error stacks. info: 오류에 대한 추가 정보가 포함된 객체입니다. componentStack 필드에는 에러를 발생시킨 컴포넌트의 스택 추적과 모든 상위 컴포넌트의 이름 및 소스 위치가 포함됩니다. 상용 환경에서는 컴포넌트 이름이 최소화됩니다. 상용 환경 오류 보고를 설정한 경우 일반 JavaScript 오류 스택과 동일한 방식으로 소스 맵을 사용하여 컴포넌트 스택을 디코딩할 수 있습니다.

Returns반환값

componentDidCatch should not return anything. componentDidCatch는 아무것도 반환하지 않아야 합니다.

Caveats주의사항

• In the past, it was common to call setState inside componentDidCatch in order to update the UI and display the fallback error message. This is deprecated in favor of defining static getDerivedStateFromError. 과거에는 UI를 업데이트하고 폴백 오류 메시지를 표시하기 위해 componentDidCatch 내부에서 setState를 호출하는 것이 일반적이었습니다. static getDerivedStateFromError를 정의하는 것을 권장하기에 이 방법은 지원 중단되었습니다.

• Production and development builds of React slightly differ in the way componentDidCatch handles errors. In development, the errors will bubble up to window, which means that any window.onerror or window.addEventListener('error', callback) will intercept the errors that have been caught by componentDidCatch. In production, instead, the errors will not bubble up, which means any ancestor error handler will only receive errors not explicitly caught by componentDidCatch. React의 상용 환경과 개발 환경은 componentDidCatch가 에러를 처리하는 방식이 약간 다릅니다. 개발 환경에서는 에러가 window까지 버블링되므로, window.onerror 또는 window.addEventListener('error', callback)가 componentDidCatch가 포착한 에러를 가로채게 됩니다. 상용 환경에서는 대신 에러가 버블링되지 않으므로, 모든 조상 에러 핸들러는 componentDidCatch가 명시적으로 포착하지 않은 에러만 수신합니다.

componentDidMount()

If you define the componentDidMount method, React will call it when your component is added (mounted) to the screen. This is a common place to start data fetching, set up subscriptions, or manipulate the DOM nodes. componentDidMount 메서드를 정의하면 컴포넌트가 화면에 추가(마운트)될 때 React가 이를 호출합니다. 데이터 불러오기를 시작하거나 구독을 설정하거나 DOM 노드를 조작하는 일반적인 장소입니다.

If you implement componentDidMount, you usually need to implement other lifecycle methods to avoid bugs. For example, if componentDidMount reads some state or props, you also have to implement componentDidUpdate to handle their changes, and componentWillUnmount to clean up whatever componentDidMount was doing. componentDidMount를 구현하는 경우 일반적으로 버그를 피하기 위해 다른 생명주기 메서드를 구현해야 합니다. 예를 들어, componentDidMount가 일부 state나 props를 읽는 경우, 해당 변경 사항을 처리하기 위해 componentDidUpdate를 구현하고 componentDidMount 가 수행하던 작업을 클린업 하기 위해 componentWillUnmount도 구현해야 합니다.

class ChatRoom extends Component {
  state = {
    serverUrl: 'https://localhost:1234'
  };

  componentDidMount() {
    this.setupConnection();
  }

  componentDidUpdate(prevProps, prevState) {
    if (
      this.props.roomId !== prevProps.roomId ||
      this.state.serverUrl !== prevState.serverUrl
    ) {
      this.destroyConnection();
      this.setupConnection();
    }
  }

  componentWillUnmount() {
    this.destroyConnection();
  }

  // ...
}

See more examples. 더 많은 예시를 확인하세요.

Parameters매개변수

componentDidMount does not take any parameters. componentDidMount는 어떤 매개변수도 받지 않습니다.

Returns반환값

componentDidMount should not return anything. componentDidMount는 아무것도 반환하지 않아야 합니다.

Caveats주의사항

• When Strict Mode is on, in development React will call componentDidMount, then immediately call componentWillUnmount, and then call componentDidMount again. This helps you notice if you forgot to implement componentWillUnmount or if its logic doesn’t fully “mirror” what componentDidMount does. Strict Mode가 켜져 있으면 React는 개발 환경에서 componentDidMount를 호출한 다음 즉시 componentWillUnmount를 호출하고 componentDidMount를 다시 호출합니다. 이렇게 하면 componentWillUnmount를 구현하는 것을 잊어버렸거나 그 로직이 componentDidMount의 동작을 완전히 “미러링”하지 않는지 확인할 수 있습니다.

• Although you may call setState immediately in componentDidMount, it’s best to avoid that when you can. It will trigger an extra rendering, but it will happen before the browser updates the screen. This guarantees that even though the render will be called twice in this case, the user won’t see the intermediate state. Use this pattern with caution because it often causes performance issues. In most cases, you should be able to assign the initial state in the constructor instead. It can, however, be necessary for cases like modals and tooltips when you need to measure a DOM node before rendering something that depends on its size or position. componentDidMount에서 setState를 즉시 호출할 수도 있지만 가능하면 피하는 것이 가장 좋습니다. 브라우저가 화면을 업데이트하기 전에 추가 렌더링을 촉발하기 때문입니다. 이 경우 render가 두 번 호출되더라도 사용자에게 중간 state가 표시되지 않습니다. 이 패턴은 종종 성능 문제를 일으키므로 주의해서 사용하세요. 대부분의 경우 constructor에서 초기 state를 대신 할당할 수 있어야 합니다. 그러나 모달이나 툴팁과 같이, 크기나 위치에 따라 달라지는 것을 렌더링하기 전에 DOM 노드를 측정해야 하는 경우에는 필요할 수 있습니다.

componentDidUpdate(prevProps, prevState, snapshot?)

If you define the componentDidUpdate method, React will call it immediately after your component has been re-rendered with updated props or state. This method is not called for the initial render. componentDidUpdate 메서드를 정의하면 React는 컴포넌트가 업데이트된 props나 state로 다시 렌더링된 직후에 해당 메서드를 호출합니다. 이 메서드는 초기 렌더링에는 호출되지 않습니다.

You can use it to manipulate the DOM after an update. This is also a common place to do network requests as long as you compare the current props to previous props (e.g. a network request may not be necessary if the props have not changed). Typically, you’d use it together with componentDidMount and componentWillUnmount: 업데이트 후 DOM을 조작하는 데 사용할 수 있습니다. 또한 현재 props를 이전 props와 비교하는 네트워크 요청을 수행하는 일반적인 장소이기도 합니다(예: props가 변경되지 않은 경우 네트워크 요청이 필요하지 않을 수 있음). 일반적으로 componentDidMount 및 componentWillUnmount와 함께 사용합니다:

class ChatRoom extends Component {
  state = {
    serverUrl: 'https://localhost:1234'
  };

  componentDidMount() {
    this.setupConnection();
  }

  componentDidUpdate(prevProps, prevState) {
    if (
      this.props.roomId !== prevProps.roomId ||
      this.state.serverUrl !== prevState.serverUrl
    ) {
      this.destroyConnection();
      this.setupConnection();
    }
  }

  componentWillUnmount() {
    this.destroyConnection();
  }

  // ...
}

See more examples. 더 많은 예시를 확인하세요.

Parameters매개변수

• prevProps: Props before the update. Compare prevProps to this.props to determine what changed. prevProps: 업데이트 전 props. prevProps와 this.props를 비교하여 변경된 내용을 확인합니다.

• prevState: State before the update. Compare prevState to this.state to determine what changed. prevState: 업데이트 전 state. prevState를 this.state와 비교하여 변경된 내용을 확인합니다.

• snapshot: If you implemented getSnapshotBeforeUpdate, snapshot will contain the value you returned from that method. Otherwise, it will be undefined. snapshot: getSnapshotBeforeUpdate를 구현한 경우, 스냅샷에는 해당 메서드에서 반환한 값이 포함됩니다. 그렇지 않으면 undefined가 될 것입니다.

Returns반환값

componentDidUpdate should not return anything. componentDidUpdate는 아무것도 반환하지 않아야 합니다.

Caveats주의사항

• componentDidUpdate will not get called if shouldComponentUpdate is defined and returns false. shouldComponentUpdate가 정의되어 있으면 componentDidUpdate가 호출되지 않고 false를 반환합니다.

• The logic inside componentDidUpdate should usually be wrapped in conditions comparing this.props with prevProps, and this.state with prevState. Otherwise, there’s a risk of creating infinite loops. componentDidUpdate 내부의 로직은 일반적으로 this.props를 prevProps와 비교하고 this.state를 prevState와 비교하는 조건으로 감싸야 합니다. 그렇지 않으면 무한 루프가 생성될 위험이 있습니다.

• Although you may call setState immediately in componentDidUpdate, it’s best to avoid that when you can. It will trigger an extra rendering, but it will happen before the browser updates the screen. This guarantees that even though the render will be called twice in this case, the user won’t see the intermediate state. This pattern often causes performance issues, but it may be necessary for rare cases like modals and tooltips when you need to measure a DOM node before rendering something that depends on its size or position. componentDidUpdate에서 setState를 바로 호출할 수도 있지만, 가능하면 피하는 것이 좋습니다. 이러한 경우 추가 렌더링을 촉발될 수 있지만, 브라우저가 화면을 업데이트하기 전에 발생합니다. 이 경우 render가 두 번 호출되더라도 사용자에게 중간 state가 표시되지 않습니다. 이 패턴은 종종 성능 문제를 일으키지만 모달이나 툴팁처럼 드물게 크기나 위치에 따라 달라지는 것을 렌더링하기 전에 DOM 노드를 측정해야 하는 경우에 필요할 수 있습니다.

componentWillMount()

componentWillReceiveProps(nextProps)

componentWillUpdate(nextProps, nextState)

componentWillUnmount()

If you define the componentWillUnmount method, React will call it before your component is removed (unmounted) from the screen. This is a common place to cancel data fetching or remove subscriptions. componentWillUnmount 메서드를 정의하면 React는 컴포넌트가 화면에서 제거(마운트 해제)되기 전에 이 메서드를 호출합니다. 이는 데이터 불러오기를 취소하거나 구독을 제거하는 로직을 작성하는 일반적인 장소입니다.

The logic inside componentWillUnmount should “mirror” the logic inside componentDidMount. For example, if componentDidMount sets up a subscription, componentWillUnmount should clean up that subscription. If the cleanup logic in your componentWillUnmount reads some props or state, you will usually also need to implement componentDidUpdate to clean up resources (such as subscriptions) corresponding to the old props and state. componentWillUnmount 내부의 로직은 componentDidMount. 내부의 로직을 “미러링”해야 합니다. 예를 들어 componentDidMount가 구독을 셋업 하면 componentWillUnmount는 해당 구독을 클린업 해야 합니다. componentWillUnmount의 클린업 로직이 일부 props나 state를 읽는 경우, 일반적으로 이전 props나 state에 해당하는 리소스(예: 구독)를 클린업 하기 위해 componentDidUpdate도 구현해야 합니다.

class ChatRoom extends Component {
  state = {
    serverUrl: 'https://localhost:1234'
  };

  componentDidMount() {
    this.setupConnection();
  }

  componentDidUpdate(prevProps, prevState) {
    if (
      this.props.roomId !== prevProps.roomId ||
      this.state.serverUrl !== prevState.serverUrl
    ) {
      this.destroyConnection();
      this.setupConnection();
    }
  }

  componentWillUnmount() {
    this.destroyConnection();
  }

  // ...
}

See more examples. 더 많은 예시를 확인하세요.

Parameters매개변수

componentWillUnmount does not take any parameters. componentWillUnmount는 매개변수를 받지 않습니다.

Returns반환값

componentWillUnmount should not return anything. componentWillUnmount는 아무것도 반환하지 않아야 합니다.

Caveats주의사항

• When Strict Mode is on, in development React will call componentDidMount, then immediately call componentWillUnmount, and then call componentDidMount again. This helps you notice if you forgot to implement componentWillUnmount or if its logic doesn’t fully “mirror” what componentDidMount does. Strict Mode가 켜져 있으면 React는 개발 환경에서 componentDidMount를 호출한 다음 즉시 componentWillUnmount를 호출하고 다시 componentDidMount를 호출합니다. 이렇게 하면 componentWillUnmount를 구현하는 것을 잊어버렸거나 그 로직이 componentDidMount가 하는 일을 완전히 “미러링”하지 않는지 알 수 있습니다.

forceUpdate(callback?)

Forces a component to re-render. 컴포넌트를 강제로 다시 렌더링합니다.

Usually, this is not necessary. If your component’s render method only reads from this.props, this.state, or this.context, it will re-render automatically when you call setState inside your component or one of its parents. However, if your component’s render method reads directly from an external data source, you have to tell React to update the user interface when that data source changes. That’s what forceUpdate lets you do. 일반적으로는 필요하지 않습니다. 컴포넌트의 render 메서드가 this.props, this.state 또는 this.context,에서만 읽는 경우, 컴포넌트 내부 또는 부모 중 하나에서 setState를 호출하면 자동으로 다시 렌더링됩니다. 하지만 컴포넌트의 render 메서드가 외부 데이터 소스로부터 직접 읽어오는 경우, 데이터 소스가 변경될 때 사용자 인터페이스를 업데이트하도록 React에 지시해야 합니다. 이것이 바로 forceUpdate가 할 수 있는 일입니다.

Try to avoid all uses of forceUpdate and only read from this.props and this.state in render. forceUpdate의 모든 사용을 피하고 render에서 this.props와 this.state에서만 읽도록 하세요.

Parameters매개변수

• optional callback If specified, React will call the callback you’ve provided after the update is committed. 선택적 callback을 지정하면, React는 업데이트가 커밋된 후 사용자가 제공한 callback 을 호출합니다.

Returns반환값

forceUpdate does not return anything. forceUpdate는 아무 것도 반환하지 않습니다.

Caveats주의사항

• If you call forceUpdate, React will re-render without calling shouldComponentUpdate. forceUpdate를 호출하면 React는 shouldComponentUpdate.를 호출하지 않고 리렌더링합니다.

getChildContext()

Lets you specify the values for the legacy context is provided by this component. 이 컴포넌트가 제공하는 legacy 컨텍스트에 대한 값을 지정할 수 있습니다.

getSnapshotBeforeUpdate(prevProps, prevState)

If you implement getSnapshotBeforeUpdate, React will call it immediately before React updates the DOM. It enables your component to capture some information from the DOM (e.g. scroll position) before it is potentially changed. Any value returned by this lifecycle method will be passed as a parameter to componentDidUpdate. getSnapshotBeforeUpdate를 구현하면 React가 DOM을 업데이트하기 바로 전에 호출합니다. 이를 통해 컴포넌트가 잠재적으로 변경되기 전에 DOM에서 일부 정보(예: 스크롤 위치)를 캡처할 수 있습니다. 이 생명주기 메서드가 반환하는 모든 값은 componentDidUpdate에 매개변수로 전달됩니다.

For example, you can use it in a UI like a chat thread that needs to preserve its scroll position during updates: 예를 들어 업데이트 중에 스크롤 위치를 유지해야 하는 채팅 스레드와 같은 UI에서 이 기능을 사용할 수 있습니다:

class ScrollingList extends React.Component {
  constructor(props) {
    super(props);
    this.listRef = React.createRef();
  }

  getSnapshotBeforeUpdate(prevProps, prevState) {
    // Are we adding new items to the list?
    // 목록에 새 항목을 추가하고 있나요?
    // Capture the scroll position so we can adjust scroll later.
    // 나중에 스크롤을 조정할 수 있도록 스크롤 위치를 캡처합니다.
    if (prevProps.list.length < this.props.list.length) {
      const list = this.listRef.current;
      return list.scrollHeight - list.scrollTop;
    }
    return null;
  }

  componentDidUpdate(prevProps, prevState, snapshot) {
    // If we have a snapshot value, we've just added new items.
    // 스냅샷 값이 있으면 방금 새 항목을 추가한 것입니다.
    // Adjust scroll so these new items don't push the old ones out of view.
    // 새 항목이 기존 항목을 화면 밖으로 밀어내지 않도록 스크롤을 조정합니다.
    // (snapshot here is the value returned from getSnapshotBeforeUpdate)
    // (여기서 스냅샷은 getSnapshotBeforeUpdate에서 반환된 값입니다.)
    if (snapshot !== null) {
      const list = this.listRef.current;
      list.scrollTop = list.scrollHeight - snapshot;
    }
  }

  render() {
    return (
      <div ref={this.listRef}>{/* ...contents... */}</div>
    );
  }
}

In the above example, it is important to read the scrollHeight property directly in getSnapshotBeforeUpdate. It is not safe to read it in render, UNSAFE_componentWillReceiveProps, or UNSAFE_componentWillUpdate because there is a potential time gap between these methods getting called and React updating the DOM. 위의 예시에서는 getSnapshotBeforeUpdate에서 직접 scrollHeight 속성을 읽는 것이 중요합니다. 이러한 메서드가 호출되는 시점과 React가 DOM을 업데이트하는 시점 사이에 잠재적인 시간 간격이 있기 때문에 render, UNSAFE_componentWillReceiveProps 또는 UNSAFE_componentWillUpdate에서 읽어오는 것은 안전하지 않습니다.

Parameters매개변수

• prevProps: Props before the update. Compare prevProps to this.props to determine what changed. 업데이트 전 props. prevProps와 this.props를 비교하여 변경된 내용을 확인합니다.

• prevState: State before the update. Compare prevState to this.state to determine what changed. prevState: 업데이트 전 state. prevState를 this.state와 비교하여 변경된 내용을 확인합니다.

Returns반환값

You should return a snapshot value of any type that you’d like, or null. The value you returned will be passed as the third argument to componentDidUpdate. 원하는 유형의 스냅샷 값 또는 null을 반환해야 합니다. 반환한 값은 componentDidUpdate의 세 번째 인자로 전달됩니다.

Caveats주의사항

• getSnapshotBeforeUpdate will not get called if shouldComponentUpdate is defined and returns false. shouldComponentUpdate가 정의되어 있고 false를 반환하는 경우 getSnapshotBeforeUpdate가 호출되지 않습니다.

render()

The render method is the only required method in a class component. render 메서드는 클래스 컴포넌트에서 유일하게 필요한 메서드입니다.

The render method should specify what you want to appear on the screen, for example: 예를 들어 render 메서드에는 화면에 표시할 내용을 지정해야 합니다:

import { Component } from 'react';

class Greeting extends Component {
  render() {
    return <h1>Hello, {this.props.name}!</h1>;
  }
}

React may call render at any moment, so you shouldn’t assume that it runs at a particular time. Usually, the render method should return a piece of JSX, but a few other return types (like strings) are supported. To calculate the returned JSX, the render method can read this.props, this.state, and this.context. React는 언제든 render를 호출할 수 있으므로 특정 시간에 실행된다고 가정해서는 안 됩니다. 일반적으로 render 메서드는 JSX를 반환해야 하지만 문자열과 같은 몇 가지 다른 반환 유형이 지원됩니다. 반환된 JSX를 계산하기 위해 렌더 메서드는 this.props, this.state, this.context를 읽을 수 있습니다.

You should write the render method as a pure function, meaning that it should return the same result if props, state, and context are the same. It also shouldn’t contain side effects (like setting up subscriptions) or interact with the browser APIs. Side effects should happen either in event handlers or methods like componentDidMount. render 메서드는 순수 함수로 작성해야 합니다. 즉, props, state 및 context가 동일한 경우 동일한 결과를 반환해야 합니다. 또한 구독 설정과 같은 사이드 이펙트를 포함하거나 브라우저 API와 상호 작용해서는 안 됩니다. 사이드 이펙트는 이벤트 핸들러나 componentDidMount와 같은 메서드에서 발생해야 합니다.

Parameters매개변수

render does not take any parameters. render는 어떠한 파라미터도 받지 않습니다.

Returns반환값

render can return any valid React node. This includes React elements such as <div />, strings, numbers, portals, empty nodes (null, undefined, true, and false), and arrays of React nodes. render는 유효한 모든 React 노드를 반환할 수 있습니다. 여기에는 <div />, 문자열, 숫자, 포털, 빈 노드(null, undefined, true, false), React 노드 배열과 같은 React 요소가 포함됩니다.

Caveats주의사항

• render should be written as a pure function of props, state, and context. It should not have side effects. render는 props, state, context의 순수한 함수로 작성되어야 합니다. 사이드 이펙트가 없어야 합니다.

• render will not get called if shouldComponentUpdate is defined and returns false. shouldComponentUpdate가 정의되고 false을 반환하면 render가 호출되지 않습니다.

• When Strict Mode is on, React will call render twice in development and then throw away one of the results. This helps you notice the accidental side effects that need to be moved out of the render method. Strict Mode가 켜져 있으면 React는 개발 환경에서 render 를 두 번 호출한 다음 결과 중 하나를 버립니다. 이렇게 하면 render 메서드에서 제거해야 하는 실수로 발생한 부작용을 알아차릴 수 있습니다.

• There is no one-to-one correspondence between the render call and the subsequent componentDidMount or componentDidUpdate call. Some of the render call results may be discarded by React when it’s beneficial. render 호출과 후속 componentDidMount 또는 componentDidUpdate 호출 사이에는 일대일 대응이 없습니다. redner호출 결과 중 일부는 유익할 때 React에 의해 버려질 수 있습니다.

setState(nextState, callback?)

Call setState to update the state of your React component. setState를 호출하면 React 컴포넌트의 state를 업데이트합니다.

class Form extends Component {
  state = {
    name: 'Taylor',
  };

  handleNameChange = (e) => {
    const newName = e.target.value;
    this.setState({
      name: newName
    });
  }

  render() {
    return (
      <>
        <input value={this.state.name} onChange={this.handleNameChange} />
        <p>Hello, {this.state.name}.</p>
      </>
    );
  }
}

setState enqueues changes to the component state. It tells React that this component and its children need to re-render with the new state. This is the main way you’ll update the user interface in response to interactions. setState는 컴포넌트 state에 대한 변경 사항을 큐에 넣습니다. 이 컴포넌트와 그 자식들이 새로운 state로 다시 렌더링해야 한다는 것을 React에게 알려줍니다. 이것이 상호작용에 반응하여 사용자 인터페이스를 업데이트하는 주요 방법입니다.

function handleClick() {
  console.log(this.state.name); // "Taylor"
  this.setState({
    name: 'Robin'
  });
  console.log(this.state.name); // Still "Taylor"!
                                // 여전히 "Taylor"입니다!
}

You can also pass a function to setState. It lets you update state based on the previous state: setState에 함수를 전달할 수도 있습니다. 이전 state를 기반으로 state를 업데이트할 수 있습니다:

  handleIncreaseAge = () => {
    this.setState(prevState => {
      return {
        age: prevState.age + 1
      };
    });
  }

You don’t have to do this, but it’s handy if you want to update state multiple times during the same event. 이 작업을 수행할 필요는 없지만 동일한 이벤트 중에 state를 여러 번 업데이트하려는 경우 유용합니다.

Parameters매개변수

• nextState: Either an object or a function. nextState: 객체 또는 함수입니다.

  • If you pass an object as nextState, it will be shallowly merged into this.state. 객체를 nextState로 전달하면 this.state에 얕게 병합됩니다.
  • If you pass a function as nextState, it will be treated as an updater function. It must be pure, should take the pending state and props as arguments, and should return the object to be shallowly merged into this.state. React will put your updater function in a queue and re-render your component. During the next render, React will calculate the next state by applying all of the queued updaters to the previous state. 함수를 nextState로 전달하면 _업데이터 함수_로 처리됩니다. 이 함수는 순수해야 하며, 보류 중인 state와 props를 인자로 받아야 하고, this.state에 얕게 병합할 객체를 반환해야 합니다. React는 업데이터 함수를 대기열에 넣고 컴포넌트를 리렌더링합니다. 다음 렌더링 중에 React는 대기열에 있는 모든 업데이터를 이전 state에 적용하여 다음 state를 계산합니다.

• optional callback: If specified, React will call the callback you’ve provided after the update is committed. 선택적 callback: 지정하면 React는 업데이트가 커밋된 후 사용자가 제공한 callback을 호출합니다.

Returns반환값

setState does not return anything. setState는 아무것도 반환하지 않습니다.

Caveats주의사항

• Think of setState as a request rather than an immediate command to update the component. When multiple components update their state in response to an event, React will batch their updates and re-render them together in a single pass at the end of the event. In the rare case that you need to force a particular state update to be applied synchronously, you may wrap it in flushSync, but this may hurt performance. setState를 컴포넌트를 업데이트하는 즉각적인 명령이 아닌 요청으로 생각하세요. 여러 컴포넌트가 이벤트에 반응하여 state를 업데이트하면 React는 업데이트를 일괄 처리하고 이벤트가 끝날 때 단일 패스로 함께 다시 렌더링합니다. 드물게 특정 state 업데이트를 강제로 동기화하여 적용해야 하는 경우, flushSync로 감쌀 수 있지만, 이 경우 성능이 저하될 수 있습니다.

• setState does not update this.state immediately. This makes reading this.state right after calling setState a potential pitfall. Instead, use componentDidUpdate or the setState callback argument, either of which are guaranteed to fire after the update has been applied. If you need to set the state based on the previous state, you can pass a function to nextState as described above. setState는 this.state를 즉시 업데이트하지 않습니다. 따라서 setState를 호출한 직후 this.state를 읽는 것은 잠재적인 함정이 될 수 있습니다. 대신, 업데이트가 적용된 후에 실행되도록 보장되는 componentDidUpdate 또는 setState callback 인자를 사용하십시오. 이전 state를 기반으로 state를 설정해야 하는 경우 위에서 설명한 대로 함수를 nextState에 전달할 수 있습니다.

shouldComponentUpdate(nextProps, nextState, nextContext)

If you define shouldComponentUpdate, React will call it to determine whether a re-render can be skipped. shouldComponentUpdate를 정의하면 React가 이를 호출하여 재렌더링을 건너뛸 수 있는지 여부를 결정합니다.

If you are confident you want to write it by hand, you may compare this.props with nextProps and this.state with nextState and return false to tell React the update can be skipped. 직접 작성하는 것이 확실하다면, this.props를 nextProps와, this.state를 nextState와 비교하고 false를 반환하여 React에 업데이트를 건너뛸 수 있음을 알릴 수 있습니다.

class Rectangle extends Component {
  state = {
    isHovered: false
  };

  shouldComponentUpdate(nextProps, nextState) {
    if (
      nextProps.position.x === this.props.position.x &&
      nextProps.position.y === this.props.position.y &&
      nextProps.size.width === this.props.size.width &&
      nextProps.size.height === this.props.size.height &&
      nextState.isHovered === this.state.isHovered
    ) {
      // Nothing has changed, so a re-render is unnecessary
      return false;
    }
    return true;
  }

  // ...
}

React calls shouldComponentUpdate before rendering when new props or state are being received. Defaults to true. This method is not called for the initial render or when forceUpdate is used. 새로운 props나 state가 수신되면 렌더링하기 전에 shouldComponentUpdate를 호출합니다. 기본값은 true입니다. 이 메서드는 초기 렌더링이나 forceUpdate가 사용될 때는 호출되지 않습니다.

Parameters매개변수

• nextProps: The next props that the component is about to render with. Compare nextProps to this.props to determine what changed. nextProps: 컴포넌트가 렌더링할 다음 props. nextProps와 this.props를 비교하여 무엇이 변경되었는지 확인합니다.
• nextState: The next state that the component is about to render with. Compare nextState to this.state to determine what changed. nextState: 컴포넌트가 렌더링할 다음 state. nextState를 this.state와 비교하여 변경된 내용을 확인합니다.
• nextContext: The next context that the component is about to render with. Compare nextContext to this.context to determine what changed. Only available if you specify static contextType (modern) or static contextTypes (legacy). nextContext: 컴포넌트가 렌더링할 다음 context. nextContext와 this.context를 비교하여 변경된 내용을 확인합니다. static contextType (최신) 이나 static contextTypes (legacy)을 지정한 경우에만 사용할 수 있습니다.

Returns반환값

Return true if you want the component to re-render. That’s the default behavior. 컴포넌트를 리렌더링하려면 true를 반환합니다. 이것이 기본 동작입니다.

Return false to tell React that re-rendering can be skipped. React에 리렌더링을 건너뛸 수 있음을 알리려면 false를 반환합니다.

Caveats주의사항

• This method only exists as a performance optimization. If your component breaks without it, fix that first. 이 방법은 오직 성능 최적화를 위해서만 존재합니다. 이 방법 없이 컴포넌트가 중단되는 경우 먼저 이 문제를 해결하세요.

• Consider using PureComponent instead of writing shouldComponentUpdate by hand. PureComponent shallowly compares props and state, and reduces the chance that you’ll skip a necessary update. shouldComponentUpdate를 직접 작성하는 대신 PureComponent를 사용하는 것을 고려해 보세요. PureComponent는 props와 state를 얕게 비교하므로 필요한 업데이트를 건너뛸 가능성이 줄어듭니다.

• We do not recommend doing deep equality checks or using JSON.stringify in shouldComponentUpdate. It makes performance unpredictable and dependent on the data structure of every prop and state. In the best case, you risk introducing multi-second stalls to your application, and in the worst case you risk crashing it. 심층적인 동일성 검사를 수행하거나 shouldComponentUpdate에서 JSON.stringify를 사용하는 것은 권장하지 않습니다. 이는 성능을 예측할 수 없게 만들고 모든 props과 state의 데이터 구조에 따라 달라집니다. 최상의 경우 애플리케이션에 몇 초씩 멈추는 현상이 발생하고 최악의 경우 애플리케이션이 충돌할 위험이 있습니다.

• Returning false does not prevent child components from re-rendering when their state changes. false를 반환해도 state가 변경될 때 자식 컴포넌트가 리렌더링되는 것을 막지는 못합니다.

• Returning false does not guarantee that the component will not re-render. React will use the return value as a hint but it may still choose to re-render your component if it makes sense to do for other reasons. false를 반환해도 컴포넌트가 리렌더링되지 않는다는 보장은 없습니다. React는 반환값을 힌트로 사용하지만 다른 이유로 컴포넌트를 다시 렌더링하는 것이 합리적일 경우 여전히 렌더링을 선택할 수 있습니다.

UNSAFE_componentWillMount()

If you define UNSAFE_componentWillMount, React will call it immediately after the constructor. It only exists for historical reasons and should not be used in any new code. Instead, use one of the alternatives: UNSAFE_componentWillMount를 정의하면 React는 constructor 바로 뒤에 이를 호출합니다. 이 함수는 역사적인 이유로만 존재하며 새로운 코드에서 사용해서는 안 됩니다. 대신 다른 대안을 사용하세요:

• To initialize state, declare state as a class field or set this.state inside the constructor. state를 초기화하려면, state를 클래스 필드로 선언하거나 constructor 내부에서 this.state를 설정하세요.
• If you need to run a side effect or set up a subscription, move that logic to componentDidMount instead. 사이드 이펙트를 실행하거나 구독을 설정해야 하는 경우 해당 로직을 componentDidMount로 옮기세요.

See examples of migrating away from unsafe lifecycles. 안전하지 않은 생명주기에서 마이그레이션하는 예시를 참조하세요.

Parameters매개변수

UNSAFE_componentWillMount does not take any parameters. UNSAFE_componentWillMount 는 어떤 매개변수도 갖지 않습니다.

Returns반환값

UNSAFE_componentWillMount should not return anything. UNSAFE_componentWillMount는 어떤 것도 반환하지 않습니다.

Caveats주의사항

• UNSAFE_componentWillMount will not get called if the component implements static getDerivedStateFromProps or getSnapshotBeforeUpdate. 컴포넌트가 static getDerivedStateFromProps 또는 getSnapshotBeforeUpdate.를 구현하는 경우 UNSAFE_componentWillMount가 호출되지 않습니다.

• Despite its naming, UNSAFE_componentWillMount does not guarantee that the component will get mounted if your app uses modern React features like Suspense. If a render attempt is suspended (for example, because the code for some child component has not loaded yet), React will throw the in-progress tree away and attempt to construct the component from scratch during the next attempt. This is why this method is “unsafe”. Code that relies on mounting (like adding a subscription) should go into componentDidMount. 이름과는 달리, 앱에서 Suspense와 같은 최신 React 기능을 사용하는 경우 UNSAFE_componentWillMount는 컴포넌트가 마운트된다는 것을 보장하지 않습니다. 렌더링 시도가 일시 중단되면(예를 들어 일부 자식 컴포넌트의 코드가 아직 로드되지 않았기 때문에) React는 진행 중인 트리를 버리고 다음 시도에서 컴포넌트를 처음부터 다시 구성하려고 시도합니다. 이것이 바로 이 메서드가 “안전하지 않은” 이유입니다. 마운팅에 의존하는 코드(예: 구독 추가)는 componentDidMount로 이동해야 합니다.

• UNSAFE_componentWillMount is the only lifecycle method that runs during server rendering. For all practical purposes, it is identical to constructor, so you should use the constructor for this type of logic instead. UNSAFE_componentWillMount는 서버 렌더링 중에 실행되는 유일한 생명주기 메서드입니다. 모든 실용적인 목적으로 볼 때 constructor와 동일하므로 이러한 유형의 로직에는 constructor를 대신 사용해야 합니다.

UNSAFE_componentWillReceiveProps(nextProps, nextContext)

If you define UNSAFE_componentWillReceiveProps, React will call it when the component receives new props. It only exists for historical reasons and should not be used in any new code. Instead, use one of the alternatives: UNSAFE_componentWillReceiveProps를 정의하면 컴포넌트가 새로운 props를 수신할 때 React가 이를 호출합니다. 이 함수는 역사적인 이유로만 존재하며 새로운 코드에서 사용해서는 안 됩니다. 대신 다른 방법을 사용하세요:

• If you need to run a side effect (for example, fetch data, run an animation, or reinitialize a subscription) in response to prop changes, move that logic to componentDidUpdate instead. prop 변경에 대한 응답으로 데이터 가져오기, 애니메이션 실행, 구독 재초기화 등의 사이드 이펙트 작업을 실행해야 하는 경우 해당 로직을 componentDidUpdate로 옮기세요.
• If you need to avoid re-computing some data only when a prop changes, use a memoization helper instead. props가 변경될 때만 일부 데이터를 다시 계산하지 않으려면 메모이제이션 헬퍼를 대신 사용하세요.
• If you need to “reset” some state when a prop changes, consider either making a component fully controlled or fully uncontrolled with a key instead. props가 변경될 때 일부 state를 “초기화”해야 하는 경우, 대신 컴포넌트를 키로 완전히 제어하거나 완전히 비제어 만드는 것을 고려하세요.
• If you need to “adjust” some state when a prop changes, check whether you can compute all the necessary information from props alone during rendering. If you can’t, use static getDerivedStateFromProps instead. props가 변경될 때 일부 state를 “조정”해야 하는 경우, 렌더링 중에 props만으로 필요한 모든 정보를 계산할 수 있는지 확인하세요. 그렇지 않은 경우 static getDerivedStateFromProps를 대신 사용하세요.

See examples of migrating away from unsafe lifecycles.

Parameters매개변수

• nextProps: The next props that the component is about to receive from its parent component. Compare nextProps to this.props to determine what changed. nextProps: 컴포넌트가 부모 컴포넌트로부터 받으려는 nextProps입니다. nextProps this.props를 비교하여 변경된 내용을 확인합니다.

• nextContext: The next context that the component is about to receive from the closest provider. Compare nextContext to this.context to determine what changed. Only available if you specify static contextType (modern) or static contextTypes (legacy). nextContext: 컴포넌트가 가장 가까운 provider로부터 받으려는 next context입니다. nextContext를 this.context와 비교하여 변경된 내용을 확인합니다. static contextType (최신) 또는 static contextTypes (legacy)를 지정한 경우에만 사용할 수 있습니다.

Returns반환값

UNSAFE_componentWillReceiveProps should not return anything. UNSAFE_componentWillReceiveProps는 아무것도 반환하지 않아야 합니다.

Caveats주의사항

• UNSAFE_componentWillReceiveProps will not get called if the component implements static getDerivedStateFromProps or getSnapshotBeforeUpdate. 컴포넌트가 static getDerivedStateFromProps 또는 getSnapshotBeforeUpdate를 구현하는 경우 UNSAFE_componentWillReceiveProps가 호출되지 않습니다.

• Despite its naming, UNSAFE_componentWillReceiveProps does not guarantee that the component will receive those props if your app uses modern React features like Suspense. If a render attempt is suspended (for example, because the code for some child component has not loaded yet), React will throw the in-progress tree away and attempt to construct the component from scratch during the next attempt. By the time of the next render attempt, the props might be different. This is why this method is “unsafe”. Code that should run only for committed updates (like resetting a subscription) should go into componentDidUpdate. 이름과는 달리, 앱이 Suspense와 같은 최신 React 기능을 사용하는 경우 UNSAFE_componentWillReceiveProps는 컴포넌트가 해당 props을 수신한다는 것을 보장하지 않습니다. 렌더링 시도가 일시 중단되면(예를 들어 일부 자식 컴포넌트의 코드가 아직 로드되지 않았기 때문에) React는 진행 중인 트리를 버리고 다음 시도에서 컴포넌트를 처음부터 다시 구성하려고 시도합니다. 다음 렌더링을 시도할 때쯤이면 props가 달라져 있을 수 있습니다. 이것이 바로 이 메서드가 “안전하지 않은” 이유입니다. 커밋된 업데이트(예: 구독 재설정)에 대해서만 실행되어야 하는 코드는 componentDidMount로 이동해야 합니다.

• UNSAFE_componentWillReceiveProps does not mean that the component has received different props than the last time. You need to compare nextProps and this.props yourself to check if something changed. UNSAFE_componentWillReceiveProps는 컴포넌트가 지난번과 다른 props을 받았다는 것을 의미하지 않습니다. nextProps 와 this.props 를 직접 비교하여 변경된 사항이 있는지 확인해야 합니다.

• React doesn’t call UNSAFE_componentWillReceiveProps with initial props during mounting. It only calls this method if some of component’s props are going to be updated. For example, calling setState doesn’t generally trigger UNSAFE_componentWillReceiveProps inside the same component. React는 마운트하는 동안 초기 props로 UNSAFE_componentWillReceiveProps를 호출하지 않습니다. 컴포넌트의 일부 props가 업데이트될 경우에만 이 메서드를 호출합니다. 예를 들어, 일반적으로 같은 컴포넌트 내부에서 setState를 호출해도 UNSAFE_componentWillReceiveProps가 촉발되지 않습니다.

UNSAFE_componentWillUpdate(nextProps, nextState)

If you define UNSAFE_componentWillUpdate, React will call it before rendering with the new props or state. It only exists for historical reasons and should not be used in any new code. Instead, use one of the alternatives: UNSAFE_componentWillUpdate를 정의하면 React는 새로운 props나 state로 렌더링하기 전에 이를 호출합니다. 이 함수는 역사적인 이유로만 존재하며 새로운 코드에서 사용해서는 안 됩니다. 대신 다른 대안을 사용하세요:

• If you need to run a side effect (for example, fetch data, run an animation, or reinitialize a subscription) in response to prop or state changes, move that logic to componentDidUpdate instead. prop 또는 state 변경에 대한 응답으로 사이드 이펙트(예: 데이터 페치, 애니메이션 실행, 구독 다시 초기화)를 실행해야 하는 경우 해당 로직을 componentDidUpdate로 옮기세요.
• If you need to read some information from the DOM (for example, to save the current scroll position) so that you can use it in componentDidUpdate later, read it inside getSnapshotBeforeUpdate instead. 나중에 componentDidUpdate에서 사용할 수 있도록 DOM에서 일부 정보를 읽어야 하는 경우(예: 현재 스크롤 위치를 저장하기 위해), 대신 getSnapshotBeforeUpdate 내부에서 읽습니다.

See examples of migrating away from unsafe lifecycles. 안전하지 않은 생명주기에서 마이그레이션하는 예시를 참조하세요.

Parameters매개변수

• nextProps: The next props that the component is about to render with. Compare nextProps to this.props to determine what changed. nextProps: 컴포넌트가 렌더링할 다음 props. nextProps 와 this.props 를 비교하여 무엇이 변경되었는지 확인합니다.
• nextState: The next state that the component is about to render with. Compare nextState to this.state to determine what changed. nextState: 컴포넌트가 렌더링할 다음 state. nextState를 this.state와 비교하여 변경된 내용을 확인합니다.

Returns반환값

UNSAFE_componentWillUpdate should not return anything. UNSAFE_componentWillUpdate는 아무것도 반환하지 않아야 합니다.

Caveats주의사항

• UNSAFE_componentWillUpdate will not get called if shouldComponentUpdate is defined and returns false. shouldComponentUpdate가 정의된 경우 UNSAFE_componentWillUpdate는 호출되지 않으며 false를 반환합니다.

• UNSAFE_componentWillUpdate will not get called if the component implements static getDerivedStateFromProps or getSnapshotBeforeUpdate. 컴포넌트가 static getDerivedStateFromProps 또는 getSnapshotBeforeUpdate.를 구현하는 경우 UNSAFE_componentWillUpdate가 호출되지 않습니다.

• It’s not supported to call setState (or any method that leads to setState being called, like dispatching a Redux action) during componentWillUpdate. componentWillUpdate 중에 setState를 호출하는 것은 지원되지 않습니다(또는 Redux 액션 디스패치와 같이 setState가 호출되도록 유도하는 메서드).

• Despite its naming, UNSAFE_componentWillUpdate does not guarantee that the component will update if your app uses modern React features like Suspense. If a render attempt is suspended (for example, because the code for some child component has not loaded yet), React will throw the in-progress tree away and attempt to construct the component from scratch during the next attempt. By the time of the next render attempt, the props and state might be different. This is why this method is “unsafe”. Code that should run only for committed updates (like resetting a subscription) should go into componentDidUpdate. 이름과는 달리, 앱이 Suspense와 같은 최신 React 기능을 사용하는 경우 UNSAFE_componentWillUpdate가 컴포넌트의 업데이트를 보장하지는 않습니다. 렌더링 시도가 일시 중단되면(예를 들어 일부 자식 컴포넌트의 코드가 아직 로드되지 않았기 때문에) React는 진행 중인 트리를 버리고 다음 시도에서 컴포넌트를 처음부터 다시 구성하려고 시도합니다. 다음 렌더링 시도 시에는 props과 state가 달라질 수 있습니다. 이것이 바로 이 메서드가 “안전하지 않은” 이유입니다. 커밋된 업데이트(예: 구독 재설정)에 대해서만 실행되어야 하는 코드는 componentDidUpdate로 이동해야 합니다.

• UNSAFE_componentWillUpdate does not mean that the component has received different props or state than the last time. You need to compare nextProps with this.props and nextState with this.state yourself to check if something changed. UNSAFE_componentWillUpdate는 컴포넌트가 지난번과 다른 props나 state를 받았다는 것을 의미하지는 않습니다. nextProps 를 this.props와, nextState를 this.state와 직접 비교하여 변경된 사항이 있는지 확인해야 합니다.

• React doesn’t call UNSAFE_componentWillUpdate with initial props and state during mounting. React는 마운트하는 동안 초기 props와 state를 가지고 UNSAFE_componentWillUpdate를 호출하지 않습니다.

static childContextTypes

Lets you specify which legacy context is provided by this component. 이 컴포넌트가 제공하는 legacy context를 지정할 수 있습니다.

static contextTypes

Lets you specify which legacy context is consumed by this component. 이 컴포넌트가 제공하는 legacy context를 지정할 수 있습니다.

static contextType

If you want to read this.context from your class component, you must specify which context it needs to read. The context you specify as the static contextType must be a value previously created by createContext. 클래스 컴포넌트에서 this.context를 읽으려면 읽어야 하는 컨텍스트를 지정해야 합니다. static contextType으로 지정하는 컨텍스트는 이전에 createContext로 생성한 값이어야 합니다.

class Button extends Component {
  static contextType = ThemeContext;

  render() {
    const theme = this.context;
    const className = 'button-' + theme;
    return (
      <button className={className}>
        {this.props.children}
      </button>
    );
  }
}

static defaultProps

You can define static defaultProps to set the default props for the class. They will be used for undefined and missing props, but not for null props. static defaultProps를 정의하여 클래스의 기본 props을 설정할 수 있습니다. undefined props과 누락된 props에는 사용되지만 null props에는 사용되지 않습니다

For example, here is how you define that the color prop should default to 'blue': 예를 들어, 다음은 color prop이 기본 'blue'로 설정되도록 정의하는 방법입니다:

class Button extends Component {
  static defaultProps = {
    color: 'blue'
  };

  render() {
    return <button className={this.props.color}>click me</button>;
  }
}

If the color prop is not provided or is undefined, it will be set by default to 'blue': color prop이 제공되지 않거나 undefined이면, 기본 'blue'로 설정됩니다:

<>
  {/* this.props.color is "blue" */}
  <Button />

  {/* this.props.color is "blue" */}
  <Button color={undefined} />

  {/* this.props.color is null */}
  <Button color={null} />

  {/* this.props.color is "red" */}
  <Button color="red" />
</>

static propTypes

You can define static propTypes together with the prop-types library to declare the types of the props accepted by your component. These types will be checked during rendering and in development only. prop-types 라이브러리와 함께 정적 propTypes를 정의하여 컴포넌트에서 허용되는 props의 유형을 선언할 수 있습니다. 이러한 유형은 렌더링 중과 개발 중에만 확인됩니다.

import PropTypes from 'prop-types';

class Greeting extends React.Component {
  static propTypes = {
    name: PropTypes.string
  };

  render() {
    return (
      <h1>Hello, {this.props.name}</h1>
    );
  }
}

static getDerivedStateFromError(error)

If you define static getDerivedStateFromError, React will call it when a child component (including distant children) throws an error during rendering. This lets you display an error message instead of clearing the UI. static getDerivedStateFromError를 정의하면 렌더링 도중 자식 컴포넌트(멀리 떨어진 자식 포함)가 에러를 던질 때 React가 이를 호출합니다. 이렇게 하면 UI를 지우는 대신 에러 메시지를 표시할 수 있습니다.

Typically, it is used together with componentDidCatch which lets you send the error report to some analytics service. A component with these methods is called an error boundary. 일반적으로 에러 리포트를 일부 분석 서비스에 보낼 수 있는 componentDidCatch와 함께 사용됩니다. 이러한 메서드가 있는 컴포넌트를 error boundary라고 합니다.

See an example. 예시를 참조하세요.

Parameters매개변수

• error: The error that was thrown. In practice, it will usually be an instance of Error but this is not guaranteed because JavaScript allows to throw any value, including strings or even null. error: 발생한 에러입니다. 일반적으로 Error의 인스턴스가 되지만 JavaScript에서는 문자열이나 null을 포함한 모든 값을 throw할 수 있으므로 보장되지는 않습니다.

Returns반환값

static getDerivedStateFromError should return the state telling the component to display the error message. static getDerivedStateFromError는 컴포넌트에 오류 메시지를 표시하도록 지시하는 state를 반환해야 합니다.

Caveats주의사항

• static getDerivedStateFromError should be a pure function. If you want to perform a side effect (for example, to call an analytics service), you need to also implement componentDidCatch. static getDerivedStateFromError는 순수 함수여야 합니다. 예를 들어 분석 서비스를 호출하는 등의 사이트 이펙트를 수행하려면 componentDidCatch.도 구현해야 합니다.

static getDerivedStateFromProps(props, state)

If you define static getDerivedStateFromProps, React will call it right before calling render, both on the initial mount and on subsequent updates. It should return an object to update the state, or null to update nothing. static getDerivedStateFromProps를 정의하면 React는 초기 마운트 및 후속 업데이트 모두에서 render를 호출하기 바로 전에 이를 호출합니다. state를 업데이트하려면 객체를 반환하고, 아무것도 업데이트하지 않으려면 null을 반환해야 합니다.

This method exists for rare use cases where the state depends on changes in props over time. For example, this Form component resets the email state when the userID prop changes: 이 메서드는 시간이 지남에 따라 state가 props의 변화에 따라 달라지는 드문 사용 사례를 위해 존재합니다. 예를 들어, 이 Form 컴포넌트는 userID prop이 변경되면 이메일 state를 재설정합니다:

class Form extends Component {
  state = {
    email: this.props.defaultEmail,
    prevUserID: this.props.userID
  };

  static getDerivedStateFromProps(props, state) {
    // Any time the current user changes,
    // Reset any parts of state that are tied to that user.
    // In this simple example, that's just the email.
    if (props.userID !== state.prevUserID) {
      return {
        prevUserID: props.userID,
        email: props.defaultEmail
      };
    }
    return null;
  }

  // ...
}

Note that this pattern requires you to keep a previous value of the prop (like userID) in state (like prevUserID). 이 패턴을 사용하려면 props의 이전 값(예: userID)을 state(예: prevUserID)로 유지해야 한다는 점에 유의하세요.

Parameters매개변수

• props: The next props that the component is about to render with. props: 컴포넌트가 렌더링할 다음 props.

• state: The next state that the component is about to render with. state: 컴포넌트가 렌더링할 다음 state.

Returns반환값

static getDerivedStateFromProps return an object to update the state, or null to update nothing. static getDerivedStateFromProps는 state를 업데이트할 객체를 반환하거나, 아무것도 업데이트하지 않으면 null을 반환합니다.

Caveats주의사항

• This method is fired on every render, regardless of the cause. This is different from UNSAFE_componentWillReceiveProps, which only fires when the parent causes a re-render and not as a result of a local setState. 이 메서드는 원인에 관계없이 모든 렌더링에서 호출됩니다. 부모가 리렌더링을 일으킬 때만 발동하고 지역 setState의 결과가 아닐 때만 발동하는 UNSAFE_componentWillReceiveProps와는 다릅니다.

• This method doesn’t have access to the component instance. If you’d like, you can reuse some code between static getDerivedStateFromProps and the other class methods by extracting pure functions of the component props and state outside the class definition. 이 메서드에는 컴포넌트 인스턴스에 대한 접근 권한이 없습니다. 원하는 경우 클래스 정의 외부에서 순수 함수인 컴포넌트의 props와 state를 추출하여 static getDerivedStateFromProps와 다른 클래스 메서드 사이에 일부 코드를 재사용할 수 있습니다.

Usage사용법

Defining a class component클래스 컴포넌트 정의하기

To define a React component as a class, extend the built-in Component class and define a render method: React 컴포넌트를 클래스로 정의하려면 빌트인 Component 클래스를 확장하고 render 메서드를 정의합니다:

import { Component } from 'react';

class Greeting extends Component {
  render() {
    return <h1>Hello, {this.props.name}!</h1>;
  }
}

React will call your render method whenever it needs to figure out what to display on the screen. Usually, you will return some JSX from it. Your render method should be a pure function: it should only calculate the JSX. React는 화면에 표시할 내용을 파악해야 할 때마다 render 메서드를 호출합니다. 보통은 JSX를 반환합니다. render 메서드는 순수 함수여야 합니다. JSX만 계산해야 합니다.

Similarly to function components, a class component can receive information by props from its parent component. However, the syntax for reading props is different. For example, if the parent component renders <Greeting name="Taylor" />, then you can read the name prop from this.props, like this.props.name: 함수 컴포넌트와 마찬가지로 클래스 컴포넌트는 부모 컴포넌트 props로부터 정보를 받을 수 있습니다. 하지만 props를 읽는 구문은 다릅니다. 예를 들어 부모 컴포넌트가 <Greeting name="Taylor" />를 렌더링하는 경우, this.props.name과 같이 this.props에서 name prop을 읽을 수 있습니다:

Note that Hooks (functions starting with use, like useState) are not supported inside class components. 클래스 컴포넌트 내부에서는 Hook(use으로 시작하는 함수, 예를 들어 useState)이 지원되지 않습니다.

Adding state to a class component클래스 컴포넌트에 state 추가하기

To add state to a class, assign an object to a property called state. To update state, call this.setState. 클래스에 state를 추가하려면 state라는 프로퍼티에 객체를 할당합니다. state를 업데이트하려면 this.setState를 호출합니다.

Adding lifecycle methods to a class component클래스 컴포넌트에 생명주기 메서드 추가하기

There are a few special methods you can define on your class. 클래스에서 정의할 수 있는 몇 가지 특별한 메서드가 있습니다.

If you define the componentDidMount method, React will call it when your component is added (mounted) to the screen. React will call componentDidUpdate after your component re-renders due to changed props or state. React will call componentWillUnmount after your component has been removed (unmounted) from the screen. componentDidMount 메서드를 정의하면 컴포넌트가 화면에 추가(마운트)될 때 React가 이를 호출합니다. 컴포넌트가 props나 state 변경으로 인해 다시 렌더링되면 React는 componentDidUpdate를 호출합니다. 컴포넌트가 화면에서 제거(마운트 해제)된 후 React는 componentWillUnmount를 호출합니다.

If you implement componentDidMount, you usually need to implement all three lifecycles to avoid bugs. For example, if componentDidMount reads some state or props, you also have to implement componentDidUpdate to handle their changes, and componentWillUnmount to clean up whatever componentDidMount was doing. componentDidMount를 구현하는 경우 일반적으로 버그를 피하기 위해 세 가지 생명주기를 모두 구현해야 합니다. 예를 들어, componentDidMount가 일부 state나 props를 읽었다면 해당 변경 사항을 처리하기 위해 componentDidUpdate도 구현해야 하고, componentDidMount가 수행하던 작업을 클린업 하기 위해 componentWillUnmount도 구현해야 합니다.

For example, this ChatRoom component keeps a chat connection synchronized with props and state: 예를 들어 다음 ChatRoom 컴포넌트는 채팅 연결을 props 및 state와 동기화합니다:

Note that in development when Strict Mode is on, React will call componentDidMount, immediately call componentWillUnmount, and then call componentDidMount again. This helps you notice if you forgot to implement componentWillUnmount or if its logic doesn’t fully “mirror” what componentDidMount does. 개발 환경에서 Strict Mode가 켜져 있을 때 React는 componentDidMount를 호출하고, 즉시 componentWillUnmount를 호출한 다음, componentDidMount를 다시 호출합니다. 이렇게 하면 componentWillUnmount를 구현하는 것을 잊어버렸거나 그 로직이 componentDidMount의 동작을 완전히 “미러링”하지 않는지 알 수 있습니다.

Catching rendering errors with an error boundary에러 경계로 렌더링 오류 포착하기

By default, if your application throws an error during rendering, React will remove its UI from the screen. To prevent this, you can wrap a part of your UI into an error boundary. An error boundary is a special component that lets you display some fallback UI instead of the part that crashed—for example, an error message. 기본적으로 애플리케이션이 렌더링 도중 에러를 발생시키면 React는 화면에서 해당 UI를 제거합니다. 이를 방지하기 위해 UI의 일부를 *에러 경계(error boundary)*로 감싸면 됩니다. 에러 경계는 에러가 발생한 부분 대신 에러 메시지와 같은 폴백 UI를 표시할 수 있는 특수한 컴포넌트입니다.

To implement an error boundary component, you need to provide static getDerivedStateFromError which lets you update state in response to an error and display an error message to the user. You can also optionally implement componentDidCatch to add some extra logic, for example, to log the error to an analytics service. 에러 경계 컴포넌트를 구현하려면 에러에 대한 응답으로 state를 업데이트하고 사용자에게 에러 메시지를 표시할 수 있는 static getDerivedStateFromError를 제공해야 합니다. 또한 선택적으로 componentDidCatch를 구현하여 분석 서비스에 에러를 기록하는 등 몇 가지 추가 로직을 추가할 수도 있습니다.

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    // Update state so the next render will show the fallback UI.
    return { hasError: true };
  }

  componentDidCatch(error, info) {
    // Example "componentStack":
    //   in ComponentThatThrows (created by App)
    //   in ErrorBoundary (created by App)
    //   in div (created by App)
    //   in App
    logErrorToMyService(error, info.componentStack);
  }

  render() {
    if (this.state.hasError) {
      // You can render any custom fallback UI
      return this.props.fallback;
    }

    return this.props.children;
  }
}

Then you can wrap a part of your component tree with it: 그런 다음 컴포넌트 트리의 일부를 감쌀 수 있습니다:

<ErrorBoundary fallback={<p>Something went wrong</p>}>
  <Profile />
</ErrorBoundary>

If Profile or its child component throws an error, ErrorBoundary will “catch” that error, display a fallback UI with the error message you’ve provided, and send a production error report to your error reporting service. Profile 또는 자식 컴포넌트가 에러를 발생시키면 ErrorBoundary가 해당 에러를 “포착”하고 사용자가 제공한 에러 메시지와 함께 폴백 UI를 표시한 다음 상용 환경용 에러 리포트를 에러 리포트 서비스로 전송합니다.

You don’t need to wrap every component into a separate error boundary. When you think about the granularity of error boundaries, consider where it makes sense to display an error message. For example, in a messaging app, it makes sense to place an error boundary around the list of conversations. It also makes sense to place one around every individual message. However, it wouldn’t make sense to place a boundary around every avatar. 모든 컴포넌트를 별도의 에러 경계로 감쌀 필요는 없습니다. 에러 경계의 세분성에 대해 생각할 때 에러 메시지를 표시하는 것이 합당한 위치를 고려하세요. 예를 들어 메시징 앱의 경우 대화 목록 주위에 에러 경계를 배치하는 것이 좋습니다. 모든 개별 메시지 주위에 에러 경계를 배치하는 것도 좋습니다. 하지만 모든 아바타 주위에 경계를 설정하는 것은 적절하지 않습니다.

Alternatives대안

Migrating a simple component from a class to a function클래스에서 함수로 간단한 컴포넌트 마이그레이션하기

Typically, you will define components as functions instead. 일반적으로 컴포넌트를 함수로 정의하는 것 대신 사용합니다.

For example, suppose you’re converting this Greeting class component to a function: 예를 들어 Greeting 클래스 컴포넌트를 함수로 변환한다고 가정해 보겠습니다:

Define a function called Greeting. This is where you will move the body of your render function. Greeting이라는 함수를 정의합니다. 여기서 render 함수의 본문을 움직일 것입니다.

function Greeting() {
  // ... move the code from the render method here ...
}

Instead of this.props.name, define the name prop using the destructuring syntax and read it directly: this.props.name 대신 파괴 구문을 사용하여 name prop을 정의하고 직접 읽습니다:

function Greeting({ name }) {
  return <h1>Hello, {name}!</h1>;
}

Here is a complete example: 다음은 완성된 코드입니다:

Migrating a component with state from a class to a function클래스에서 함수로 state가 있는 컴포넌트 마이그레이션하기

Suppose you’re converting this Counter class component to a function: 다음 Counter 클래스 컴포넌트를 함수로 변환한다고 가정해 봅시다:

Start by declaring a function with the necessary state variables: 필요한 state 변수로 함수를 선언하는 것부터 시작하세요:

import { useState } from 'react';

function Counter() {
  const [name, setName] = useState('Taylor');
  const [age, setAge] = useState(42);
  // ...

Next, convert the event handlers: 그런 다음, 이벤트 핸들러를 변환하세요:

function Counter() {
  const [name, setName] = useState('Taylor');
  const [age, setAge] = useState(42);

  function handleNameChange(e) {
    setName(e.target.value);
  }

  function handleAgeChange() {
    setAge(age + 1);
  }
  // ...

Finally, replace all references starting with this with the variables and functions you defined in your component. For example, replace this.state.age with age, and replace this.handleNameChange with handleNameChange. 마지막으로, this로 시작하는 모든 ref를 컴포넌트에서 정의한 변수 및 함수로 바꾸세요. 예를 들어, this.state.age를 age로 바꾸고, this.handleNameChange를 handleNameChange로 바꾸세요.

Here is a fully converted component: 다음은 완전히 변환된 컴포넌트입니다:

Migrating a component with lifecycle methods from a class to a function생명주기 메서드가 있는 컴포넌트를 클래스에서 함수로 마이그레이션하기

Suppose you’re converting this ChatRoom class component with lifecycle methods to a function: 생명주기 메서드가 있는 ChatRoom 클래스 컴포넌트를 함수로 변환한다고 가정해 보겠습니다:

First, verify that your componentWillUnmount does the opposite of componentDidMount. In the above example, that’s true: it disconnects the connection that componentDidMount sets up. If such logic is missing, add it first. 먼저, componentWillUnmount가 componentDidMount.와 반대 동작을 하는지 확인합니다. 위의 예시에서는 componentDidMount가 설정한 연결을 끊어버리는 것이 맞습니다. 이러한 로직이 누락된 경우 먼저 추가하세요.

Next, verify that your componentDidUpdate method handles changes to any props and state you’re using in componentDidMount. In the above example, componentDidMount calls setupConnection which reads this.state.serverUrl and this.props.roomId. This is why componentDidUpdate checks whether this.state.serverUrl and this.props.roomId have changed, and resets the connection if they did. If your componentDidUpdate logic is missing or doesn’t handle changes to all relevant props and state, fix that first. 다음으로, componentDidUpdate 메서드가 componentDidMount에서 사용 중인 모든 props와 state의 변경을 처리하는지 확인합니다. 위 예시에서 componentDidMount는 setupConnection을 호출하여 this.state.serverUrl과 this.props.roomId를 읽습니다. 이것이 바로 componentDidUpdate가 this.state.serverUrl과 this.props.roomId가 변경되었는지 확인하고, 변경된 경우 연결을 재설정하는 이유입니다. componentDidUpdate 로직이 누락되었거나 모든 관련 props와 state의 변경 사항을 처리하지 않는 경우, 먼저 이 부분을 수정하세요.

In the above example, the logic inside the lifecycle methods connects the component to a system outside of React (a chat server). To connect a component to an external system, describe this logic as a single Effect: 위의 예시에서, 생명주기 메서드 내부의 로직은 컴포넌트를 React 외부의 시스템(채팅 서버)에 연결합니다. 컴포넌트를 외부 시스템에 연결하려면 해당 로직을 하나의 Effect로 설명하세요.

import { useState, useEffect } from 'react';

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

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

  // ...
}

This useEffect call is equivalent to the logic in the lifecycle methods above. If your lifecycle methods do multiple unrelated things, split them into multiple independent Effects. Here is a complete example you can play with: 이 useEffect 호출은 위의 생명주기 메서드의 로직과 동일합니다. 생명주기 메서드가 서로 관련이 없는 여러 가지 작업을 수행하는 경우, 여러 개의 독립적인 Effect로 분할하세요. 다음은 전체 예제입니다:

Migrating a component with context from a class to a function컨텍스트가 있는 컴포넌트를 클래스에서 함수로 마이그레이션하기

In this example, the Panel and Button class components read context from this.context: 다음 예시에서 Panel 및 Button 클래스 컴포넌트는 this.context에서 컨텍스트를 읽습니다:

When you convert them to function components, replace this.context with useContext calls: 함수 컴포넌트로 변환할 때, this.context를 useContext 호출로 바꾸세요: