라이프 사이클 방법을 알고 있다면 50%의 React를 이해했다고 할 수 있습니다.

라이프 사이클에 대해 이야기하기 전에

우선 전제로 다음과 같은 말을 할 수 있다.
React는 원래 상태의 관리, 업데이트를 묘사에 적절하게 반영하는 라이브러리입니다.또한 어셈블리의 가장 큰 역할은 드로잉입니다.
그림을 효율적으로 표시하고 업데이트하기 위해서는 Component의 라이프 사이클을 이해하는 것이 필수적입니다.

라이프 사이클

클래스 어셈블리를 처리할 때 주기는 크게 3 기간으로 나뉩니다.마운팅(마운트 시), 업데이트(업데이트 시), 언마운팅(마운트 해제 시) 순으로 표시됩니다.
공식적으로도 아래의 그림을 소개했기 때문에 이곳을 바탕으로 설명한다.

React lifecycle methods diagram

마운트 시

어셈블리 이전 시간대를 표시합니다.

constructor()

getDerivedStateFromProps()//비일반 수명주기

render()//여기 그리기

componentDidMount()

component Did Mount에서 묘사한 후에 변경을 하려면 묘사한 후에야 완성할 수 있는 일을 여기에서 진행한다.겸사겸사 말씀드리지만, 처음에 렌더가 됐을 때만 이 기간에 들어갑니다.
예를 들어 사용자 일람을 표시하는 UI의 경우 기본 테이블의 제목과 사용자가 완성되기 전에 Loading... 표시가 마운팅 시 렌더와 같습니다.그리기가 완료되면 componentDidMount 사용자가 한눈에 볼 수 있는 API를 두드립니다.

업데이트 시간

구성 요소를 표시하고 상태를 업데이트하는 시간입니다.

getDerivedStateFromProps()//비일반 수명주기

shouldComponentUpdate()//일반 수명주기

render()

getSnapshotBeforeUpdate()//비일반 수명주기

componentDidUpdate()

State를 업데이트한 후 1~5의 순서에 따라 방법을 호출하고 다시 그립니다.
아까 예에서 componentDidMount에서 사용자가 한눈에 보는 API를 두드린 후에 완성되면 데이터가 State의users에 들어갑니다.

state = {
  users: [
    // ここの部分に入る
  ]
}

이 users가 [] 에서 [{id: 1, name: 'hogehoge'}] 로 업데이트되어 다시 그리기 > 테이블에 사용자를 표시할 수 있음을 감지했습니다.
그렇다면 예를 들어 componentDidUpdate() 어느 시기에 사용해야 하는가.
새로운 사용자를 추가하고 싶으시죠.UI에서 요약 테이블에서 新規登録 버튼을 누르면 사용자 이름을 입력 > 로그인으로 설정하여 추가 모드가 나타납니다.
이 경우 로그인을 눌러 API를 두드려post를 진행하지만 발송이 끝난 State의 변경을 검출하여 사용자가 한눈에 볼 수 있습니다.

componentDidUpdate(prevProps) {
  if(!prevProps.succeeded && this.props.succeeded) {
    // ユーザー一覧を再取得
  }
}

이때 이해하기 어려운 것은 prevProps입니다.읽으면 글자처럼 옛날 Props야.그러면 componentDidUpdate 에서 업데이트된 Props 또는 State와 업데이트된 Props 또는 State를 비교할 수 있습니다.따라서 특정 상태(Props)가 업데이트될 때만 일부 처리가 가능합니다.

마운트 해제

다른 구성 요소로 이동할 때만 호출됩니다.

componentWillUnmount()

현재 구성 요소를 제거하기 전에 호출하는 방법입니다.
흔히 무시되는 것은 ComponentDidMount 애니메이션과 타이머를 설정한 경우componentWillUnmount 폐기하는 것이다.그렇지 않으면 새 구성 요소의 순환이 시작된 후에도 해당 메모리가 방출되지 않습니다.

unsafe 방법에 관하여

사실 이전에는 또 다른 생명주기 방법이 있었다.(지금도 하고 있지만 추천하지 않음) 예를 들어

componentWillMount()

componentWillUpdate()

componentWillReceiveProps()

의 총체.만약 자신의 프로젝트에서 이것들을 발견한다면 몰래 고쳐 쓸 수 있다.
그나저나 전적으로 개인적인 견해지만 결과적으로 생명주기 방법이 많으면 어디서 무엇이 바뀌었는지 등 시기가 어려워진다.나는 사람에게 부드럽지 않은 코드는 쉽게 할 수 있다고 생각한다.
따라서 나는 기본적으로 구성 요소의 설계를 해서 componentDidMount, componentDidUpdate에서 실현할 수 있도록 해야 한다고 생각한다.
그 절차는 후크스의 use Effect에 의해 계승되었습니까?

기능 구성 요소의 라이프 사이클

이전에는 클래스 구성 요소가 아니면 생명주기를 사용할 수 없었다.그러나 훅스의 등장으로 Functional Component도 생명주기를 사용할 수 있다.
사용useEffect을 통해 특정 State의 업데이트를 간단하게 검사할 수 있습니다.

React.useEffect(() => {
  // なんかやる    
}, [// 検知したいState ])

예를 들어 오류 코드를 검출한 후 뭔가를 하고 싶은 경우 다음과 같은 느낌이 든다.

const [code, setErrCode] = React.useState<string>('')
  React.useEffect(() => {
    if (code) {
      // codeが変更されたら何かやる
    }
  }, [code])

라이프 사이클 방법의 문제점?

상태의 관리, 갱신을 적절하게 묘사하기 위해서는 필수적인 생명주기 방법이라고 할 수 있지만 문제가 발생하는 경우도 있다.
흔히 볼 수 있는 것은componentDidUpdate 내에 if가 난립되어 업데이트된 검사가 적절히 진행되었는지 알기 어렵다는 것이다.
이 문제는 생명주기 방법이 좋지 않은 것이 아니라 Component의 디자인에 거의 문제가 있는 것이다.
Component가 너무 크고 기능이 너무 많다고 할 수 있다.
다음에는 Component 디자인을 보도할 예정입니다.