> 웹 프론트엔드 > JS 튜토리얼 > 후크가 있는 React에는 수명 주기가 존재하지 않습니다.

후크가 있는 React에는 수명 주기가 존재하지 않습니다.

DDD
풀어 주다: 2024-11-14 15:18:02
원래의
873명이 탐색했습니다.

Lifecycle doesn

아주 오래전에는 클래스와 함께 React를 사용했었는데 기억하시나요?

당시에는 특정 순간에 실행될 콜백을 허용하는 클래스에 대한 메서드인 수명 주기 메서드 개념이 있었습니다. 세 가지 주요 요소: 마운트 시, 업데이트 시, 마운트 해제 시.

오래되었지만 골드 클래스

이것이 중요했습니다. 클래스 구성 요소에서 반환된 JSX는 렌더링 메서드에서 만들어졌고, 구성 요소의 this에 연결된 상태와 앱 개발자는 특정 순간에 작업을 수행하는 방법을 알 수 있는 방법이 필요했습니다. 우리는 부품의 수명에 대한 아이디어를 갖고 있었습니다:

  • componentDidMount는 컴포넌트가 처음으로 렌더링되어 DOM에 요소를 추가하는 순간이며 API 요청과 같은 부작용 및 연결이 시작되는 순간입니다.
  • shouldComponentUpdate를 사용하면 다음 props와 상태를 비교하고 부울 값을 반환하여 다시 렌더링을 건너뛸 수 있는지 여부를 정의하는 로직을 수동으로 설정할 수 있습니다.
  • componentDidUpdate는 상태나 소품이 변경되는 순간입니다. 렌더 메서드를 다시 호출하고 ID 차이에 대한 조정 변경을 수행하고 DOM에 적용합니다. 상태를 새 소품과 동기화하고 논리 작업을 수행하는 데 좋습니다.
  • componentWillUnmount는 React가 DOM에서 요소를 제거하는 경우이며, 항목을 정리하고 메모리 누수를 방지할 수 있는 좋은 장소였습니다.

물론, React 상태 업데이트와 연결되지 않는 외부 데이터를 사용하는 경우 다시 렌더링을 수동으로 실행할 수 있는 forceUpdate와 같은 중요한 API도 있습니다.

개념적 수준에서는 앱 흐름을 보다 직접적으로 수행할 수 있는 방법이 있습니다. 라이프사이클 메소드는 DOM 요소의 유사한 라이프사이클을 따랐으며, 메모 및 forceUpdate를 직접 수행할 수 있었고, 상태 동기화는 로직을 수행하는 기본 방법이었습니다.

이러한 직접성은 단순함으로 보였고 반응형 모델에 비해 이러한 개념을 배우는 것이 더 쉬웠습니다. 그런데 후크가 도착하고 모든 것이 바뀌었습니다.

이름없는 반응성

전환이 혼란스러웠습니다. 첫째, 개발자가 가지고 있는 React 모델의 개념적 비전을 쉽게 유지하기 위한 검색에서 많은 커뮤니케이션에서 Hooks 모델의 유사점을 보여주려고 노력했습니다. 3가지 주요 라이프사이클 메소드를 갖기 위해 useEffect를 사용한 해결 방법을 보여주었습니다.

// componentDidMount
 useEffect(() => {
    // code...

    // componentWillUnmount:
    return function cleanup() {
      // code...
    };
  }, []);

// componentDidUpdate
 useEffect(() => {
    // code...

  }, [dependencyState, dependencyProp]);
로그인 후 복사
로그인 후 복사

그래서 Hook으로 만들어진 새로운 React 코드의 대부분은 이 아이디어를 따랐고, 상태를 동기화하기 시작하는 것은 자연스러운 과정이었습니다. 라이프사이클 메소드에 대한 동일한 아이디어를 유지하기 위해 setState를 호출하고 다시 렌더링 프로세스를 트리거하는 곳이었습니다.

무엇이 문제인가요?

동기화 상태가 문제가 되고, useEffect를 잘못 사용하는 것이 문제가 되고, 이중 재렌더링이 문제가 되고, 너무 많은 재렌더링이 문제가 되고, 성능이 문제가 됩니다.

적어도 나에게는 React의 이 단계가 약간 혼란스럽습니다. 왜냐하면 후크로의 전환은 비록 조잡하더라도 반응형 모델로의 전환이었기 때문입니다. 그러나 의사소통은 실제로 큰 변화가 없다는 것이었습니다. 반응성 개념과 이론에 대한 내용은 없으며 수년 동안 React를 사용했지만 반응성과 솔리드에 대한 Ryan Carniato의 블로그 게시물을 읽으면서 반응성을 실제로 이해하기 시작했습니다.

useEffect에 오용이 있다는 것을 알면서도 그 이유를 정말로 이해하지 못했고, 반응성에 대한 개념적 이론이 부족하여 후크로 실수를 저지르기가 너무 쉽습니다. useEffect는 어떤 사람들에게는 “useFootgun”이라고 불리며 가장 싫어하는 후크가 되었습니다. 요점은 오늘날 우리가 볼 수 있는 useEffect의 모든 문제로 표현되는 React에는 개념적 혼란이 있다는 것입니다.

useEffect 문제는 ​​문제의 원인이 아니라 결과입니다.

후크가 있는 수명주기는 어떻습니까?

그럼 바로 이겁니다. 반응성 개념에는 생명주기가 없습니다.

변화가 생기면 그에 반응하여 파생되고 부작용이 발생합니다. 결과는 원인이 아니라 결과입니다. 상태 동기화도 없고 마운트 및 마운트 해제 개념도 없습니다.

마운트 해제 전 첫 번째, 10번째 또는 마지막 렌더링인지는 중요하지 않으며 후크는 이를 신경 쓰지 않습니다. 그런데 심지어 useEffect도 마찬가지입니다.

해 보세요:

// componentDidMount
 useEffect(() => {
    // code...

    // componentWillUnmount:
    return function cleanup() {
      // code...
    };
  }, []);

// componentDidUpdate
 useEffect(() => {
    // code...

  }, [dependencyState, dependencyProp]);
로그인 후 복사
로그인 후 복사

각 상태 업데이트에서 실행되는 두 기능을 콘솔에서 볼 수 있습니다. 먼저 하나를 정리한 다음 효과 콜백을 수행합니다. 구독을 수행하기 위해 일부 상태 또는 소품과 함께 useEffect를 사용하는 경우 종속성이 변경될 때마다 정리 함수가 호출된 다음 새 콜백이 호출되어 구독을 다시 수행하지만 새 값을 사용합니다.

앱 코드는 단순화된 React 모델로 보아야 합니다.

function EffectExample() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    console.log('effect', count);

    return () => {
      console.log('clean up', count);
    }
  }, [count]);

  return (
    <button onClick={() => setCount((state) => state + 1)}>
      {count}
    </button>
  )
}
로그인 후 복사

이런 구성요소가 있는 경우:

UI = fn(state)
로그인 후 복사

버튼을 클릭하고 개수에 1을 더하면 개념적으로 실제로 가지고 있는 것은 다음과 같습니다.

function Example() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount((state) => state + 1)}>
      {count}
    </button>
  )
}
로그인 후 복사

클릭할 때마다 새로운 상태로 fn이 다시 호출되어 새 버전의 UI가 생성됩니다. 상태는 사용자의 작업이나 비동기 파생으로 생성되어야 하는 비동기 값에 따라 변경되어야 합니다.

이렇게 하면 깔끔한 아이디어를 유지할 수 있습니다.

  • 상태 전환으로 새로운 fn 호출이 발생합니다
  • 새로운 상태에서 UI 설명을 볼 수 있습니다
  • 다른 경우 화면을 업데이트하세요.

깔끔하고 일관된 모델입니다.

화면에서 요소를 추가, 업데이트, 제거하는 것은 렌더러의 문제입니다. 구성 요소 수준에서 중요한 것은 다음과 같습니다.

  • 상태가 변경된 경우
  • 앱이 사용자 작업을 처리할 수 있는지
  • JSX에서 반환된 구조

후크와 반응형 모델은 React가 브라우저에서 자체적으로 분리되도록 하여 앱 코드가 화면 렌더링 프로세스의 어느 순간에 있는지에 대해 덜 신경쓰게 만듭니다. 더 이상 자신의 규칙에 따라 업데이트를 강요하거나 메모를 처리하지 않아도 됩니다. 이는 앱 개발자에게는 덜 직접적이지만 모델 측면에서는 더 직접적입니다.

각 재렌더링은 구조를 생성하고 나머지는 React가 처리합니다.

위 내용은 후크가 있는 React에는 수명 주기가 존재하지 않습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

원천:dev.to
본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
인기 튜토리얼
더>
최신 다운로드
더>
웹 효과
웹사이트 소스 코드
웹사이트 자료
프론트엔드 템플릿