React: componentDidReceiveProps 부탁드립니다

왜 setup(props) 아닌가요?

내 자신의 프로젝트를 살펴보면 비슷한 요구 사항이 있는 곳에서 이 작업을 수행했음을 알 수 있습니다(다른 하나는 props를 기반으로 한 상태 청크를 파생하는 것입니다). 필요할 때 다른 props 세트를 전달하기만 하면 추가 항목만 전달하면 됩니다. 재사용할 때 어떤 props가 필요한지에 대한 지식을 복제하지 않고:

setup(props) {
  props = props || this.props
  UserActions.load(props.id)
}

@syranide 문제는 설정이 소품도 필요로 하는 메서드를 호출해야 하고, 소품도 필요한 메서드를 호출해야 하는 경우입니다... 결국 전체 구성 요소가 소품을 둘러싸고 있습니다.

+1은 현재 패턴으로 앱에 불필요한 배선을 많이 한 것 같습니다. 문제를 해결하기 위한 간결하고 표준화된 방법이 될 수 있습니다. 많은 사람들이 ComponentWillReceiveProps 내부의 this.props에 화상을 입는 것을 보았습니다. 이는 직관적이지 않다는 명백한 신호입니다.

+1, 저도 이게 답답합니다.

더 이상 이것이 문제라고 생각하지 마십시오.

+1, 소품도 많이 돌아다니고 있습니다. 위의 @insin과 유사하게 잠시 동안 기본 매개변수를 사용했습니다.

setup(props = this.props) {
  doSomething(props);
}

그러나 newProps를 전달하는 것을 잊었을 경우 발생할 수 있는 미묘한 버그로 인해 안티 패턴이라고 결정했습니다.

+1

사용할 수 없는 이유는 this.props 및 this.state _always_가 렌더링된 값에 해당하기 때문이라고 생각합니다. 이 제약 조건을 위반하지 않고 다른 렌더링을 트리거하지 않는 componentDidReceiveProps 를 구현할 수 있는 방법은 없습니다.

대부분의 경우 componentWillReceiveProps 를 사용하는 경우 실제로 는 Relay 또는 React 0.14에 대해 제안된 observe hook 과 같은 고차 구성 요소를 원합니다.

+1
또한 this.props 또는 this.state 를 변경하지 않고 componentDidReceiveProps 를 구현할 수 있습니다. 이들에서 읽기만 하면 다른 렌더를 트리거하지 않습니다. 이 제안된 함수 호출 내에서 props 또는 state에 작성하는 경우 발에 총을 쏘고 있지만 라이프 사이클의 다른 모든 메서드에서도 마찬가지입니다.

+1

shouldComponentUpdate 이 false 반환할 때 새로운 props 이벤트에 응답할 수 있기를 원하므로 제 경우에는 componentDidUpdate 사용할 수 없습니다.

+1

+1

componentWillMount 및 componentWillUpdate @iammerrick componentWillUpdate 어떻습니까?

shouldComponentUpdate가 false를 반환할 때 새 props 이벤트에 응답할 수 있기를 원하므로 제 경우에는 componentDidUpdate를 사용할 수 없습니다.

componentWillReceiveProps ?

+1

+1 이것은 DRY 코드와 논리 단순화에 도움이 됩니다.

이 스레드를 시작하는 예제를 단일 함수로 만들기 위해 초기 설정에서 componentDidReceiveProps를 호출할 수 있습니다.

componentDidReceiveProps() {
  UserActions.load(this.props.id);
}

생각?

componentWillReceiveProps() {
  setTimeout(()=> {
    if(this.isMounted()) {
      this.componentDidReceiveProps();
    }
  });
}
componentDidReceiveProps() {
  UserActions.load(this.props.id);
}

어떻게 생각하나요?

@YourDeveloperFriend 중첩 구성 요소의 계단식 시간 초과로 인해 다른 수명 주기 후크 및 렌더링 지연과 관련하여 작동하는 방식에 따라 달라집니다.

이러한 종류의 수명 주기 후크는 렌더링 전에 호출되는 것이 보장되는 패스에서 동기적으로 호출되어야 합니다. 나는 React의 코드베이스를 연구하지 않았지만 렌더링이 시간 초과에 호출되지 않는다고 가정합니다.

가장 좋은 해결책은 사전 렌더링 후크를 등록하거나 props가 변경된 구성 요소를 표시하여 렌더링 논리가 render를 호출하기 전에 componentDidReceiveProps를 호출하도록 표시하는 것입니다.

+1 부탁드립니다. 너무 못생겼다.

아니, 난 괜찮아. 더 나은 솔루션이 있습니다.

+1

componentDidReceiveProps() 이미 존재합니다. render() 합니다. 그러나 @iammerrick 의 예와 같이 렌더링을 수행하기 전에 무언가를 로드/트리거/기타해야 하는 경우가 있을 수 있습니다. 이것은 단 한 가지를 의미합니다. 당신이 뭔가를 잘못하고 있다는 것입니다.

다음과 같은 일을 할 때

setup(id) {
    UserActions.load(id);
}

구성 요소 또는 (훨씬 더 나쁜) 외부에 statefullness를 도입합니다. 왜 지금해야합니까 load() 데이터 구성 요소가 소품을 수신 할 때마다 (그들은 심지어 새로운 보장되지 않음)? 지연 로딩을 한다면 render() 메소드로 데이터를 요청하는 것이 적절한 방법입니다:

render() {
    var actions = UserActions.load(id);
    if (actions) // render
    else // show spinner or return null, etc.
}

UserActions.load = function(id) {
    if (data) return data;
    else // request the data, emit change on success
}

@robyoder , 함수에 인수를 전달하는 것은 추악하지 않습니다. 너무 장황해 보일 수 있지만 선택한 프로그래밍 언어에서는 자연스러운 현상입니다. 장황함을 줄이기 위해 여분의 수명 주기 메서드를 추가하여 API를 폐기하는 것은 확실히 추악합니다.

@me-andre, 왜 우리는 componentWillUpdate 와 componentWillReceiveProps 있습니까?

제 생각에는 그것들이 다른 목적을 수행하고 둘 다 도움이 되기 때문입니다. 이 둘이 같지 않은 것처럼 render 는 가상의 componentDidReceiveProps 와 같지 않습니다. 왜냐하면 새로운 props가 아닌 다른 이유로 호출되기 때문입니다. 또한 이전 소품에 대한 액세스 권한이 부여되지 않습니다.

이전 소품의 이점은 매번 데이터를 로드할 필요가 없다는 것입니다. props 및 변경 여부에 따라 조건부일 수 있습니다.

분명히 "[추함]은 보는 사람의 눈에 달려 있습니다." 적절한 수명 주기 메서드를 추가하는 것이 나에게 훨씬 더 깨끗한 솔루션으로 보이기 때문입니다.

이걸 보는 다른 방법이 있을지도...

주요 목표는 다음과 같습니다.

(1) 인적 오류 감소 - 매개변수 전달을 잊었거나 props = props || this.props 다시 사용했습니다.
(2) 부가 가치가 없는 상용구 코드를 줄이기 위해 - 왜 불필요하게 무언가를 작성합니까?
(3) 어떤 라이프사이클 방법을 사용할지 결정하는 인지적 부담을 줄이기 위해 - 왜 이런 생각을 해야 하는지, 왜 그날 기분에 따라 조금씩 다른 접근 방식을 사용하는지 등

따라서 솔루션 공간은 이러한 목표를 달성하기 위해 React와 React API 자체의 사용을 단순화하는 것일 수 있습니다.

이러한 목표를 염두에 두고 문제에 대해 생각한다면 일부 수명 주기 메서드를 병합할 수 있으며 초기화 대 업데이트인지 알고 싶다면 서명/인수 호출을 통해 알 수 있습니다. 예: beforeRender(prevProps, prevState) 또는 update(prevProps, prevState) .

개인적으로 수명 주기 메서드가 너무 많고 일관되게 호출되면(초기 전달 및 업데이트 시 prevProps / prevState 없이 또는 함께) 코드를 단순화하고 생산성을 높일 수 있습니다. 또한 수명 주기 메서드 이름은 꽤 길며(저는 입력하는 것보다 복사/붙여넣기를 하는 경향이 있습니다) 어느 것이 존재하는지 기억하기 어렵습니다.

@robyoder , 왜 우리가 componentWillUpdate 와 componentDidReceiveProps 둘 다 가지고 있는지에 대한 짧은 대답은 둘 사이에 엄청난 차이가 있다는 것입니다. 물론 비슷하지만 주로 componentWill 접두사가 붙습니다.

| | 상태가 변경되었습니다 | 구성 요소가 업데이트되지 않았습니다 |
| --- | --- | --- |
| componentWillUpdate() | 네 | 아니 |
| componentWillReceiveProps() | 아니 | 네 |

한 메서드는 호출되고 다른 메서드는 호출되지 않는 수명 주기 지점/조건이 있음을 알 수 있습니다. 그렇기 때문에 2가지 고유한 수명 주기 방법이 있습니다.

그러나 이 항목에 설명된 대로 componentDidReceiveProps() 는 구성 요소 상태 또는 조건을 나타내지 않으며 componentWillReceiveProps() 액세스할 수 있는 권한을 부여하지 않습니다. 유용하거나 더 쉬워 보일 수도 있고 그렇지 않을 수도 있는 약간의 구문적 설탕을 추가할 뿐입니다. 이것은 기술적인 요구 사항 이 아니라

@me-andre 당신은 저(@kmalakoff)와 @robyoder 에게 동시에 응답하고

내가 제기한 것은 아마도 위의 세 가지 목표로 현재 API에 대해 생각하는 것이 API를 단순화하여 이를 달성할 수 있는 방법에 대한 새로운 통찰력이나 관점을 제공할 수 있다는 것입니다. 물론 연습을 하고 나면 같은 장소에 오게 될 수도 있다.

운동을 해보자....

이 주제에 중요한 것이 있고 componentDidReceiveProps 추가하는 것은 API 노출 영역을 늘리기 때문에 좋은 생각이 아니라고 가정해 보겠습니다.

표와 내가 제시한 3가지 목표를 염두에 두고 API를 단순화하거나 이 스레드에 있는 사람들에게 원하는 것을 제공하고 API를 확장하지 않는 다른 방법에 대한 아이디어가 있는 사람이 있습니까? )?

@kmalakoff , 말씀하신 3가지 포인트는 만났을 때 API를 사용한다는 점에서만 API와 연결됩니다. 그들은 나쁜 디자인으로 인해 발생하지 않습니다.

첫 번째 문제는 수명 주기 메서드가 다른 인수를 취한다는 것입니다. 글쎄, 그것은 완벽하게 자연 스럽습니다. 그들은 다른 목적을 수행합니다. componentWillReceiveProps 는 이 메서드가 추가되었을 때 달이 찼기 때문이 아니라 아직 구성 요소에 할당되지 않은 props를 수신하기 위한 것이므로 props를 사용합니다. props 는 this.props 와 다를 수 있는 메서드에서만 전달됩니다. 이것은 실제로 문제가 아니라 힌트입니다.
문제 # 3은 사용할 콜백/접근 방식을 결정하기 어렵다는 것입니다. 글쎄, 그것은 내가 위에서 이야기한 방법들이 동일한 서명을 가질 때까지 실제로 문제가 되지 않는다. 대부분의 방법에서 state 및 this.state , props 및 this.props 가 모두 같으면(무의미하게 읽음) 예비 옵션에 얽히게 됩니다. 대안.
문제 # 2는 상용구 코드에 관한 것입니다... 글쎄요, React는 얇은 라이브러리입니다. 그래서 아름답고 쉽고 엄격합니다. 우리의 삶을 단순화하고 매일 작성하는 코드의 양을 줄이는 래퍼를 만들고 싶다면 왜 하지 않겠습니까? 로 게시 자신의 npm 에 따라 달라집니다 react 당신이 완료됩니다.

"수명 주기 방법이 너무 많습니다"와 관련하여 - 아직 기술적인 필요가 없는 새 콜백 요청을 중단하더라도 앞으로도 없을 것입니다. 기술적인 필요는 복잡한 구성 요소를 구현하고 작업 중에 추악한 해킹 없이는 절대적 으로 수행할 수

그리고 하나 더...
잘 설계된 React 애플리케이션에서는 우리가 이야기하는 대부분의 방법이 필요하지 않거나 거의 사용하지 않습니다. getInitialState , componentWillMount , componentWillUnmount 시간의 99%면 충분합니다. 상대적으로 큰 상용 앱인 현재 프로젝트에서 componentWillReceiveProps 는 모든 앱에서 두 번 사용됩니다. 나는 그것을 전혀 사용하지 않을 것이지만 환경(브라우저 읽기)이 불완전합니다. scrollTop 와 같은 특정 "자체 상태 저장"을 조작하거나 미래의 render 대한 레이아웃 계산에 의존합니다. props 전환과 DOM 변경 간에 수동 동기화가 필요합니다. 그러나 대부분의 "정상적인" 경우에는 props 전환이 발생하는 시점 을 알 필요가 없습니다.

@me-andre는 React로 작업한 경험을 바탕으로 API를 개선/단순화할 여지가 있다고 생각합니다. 나는 혼자가 아니기 때문에 이 문제가 처음에 제기되었고 +1-ed되고 있습니다.

귀하의 분석에 대한 피드백을 제공하여 답변하면 현상 유지에 약간 편향되어 있고 현재 API를 정당화하기 때문에 이것이 실제로 앞으로 나아갈 것이라고 생각하지 않습니다. 잠재적인 솔루션에 대한 피드백을 기꺼이 제공하겠습니다! 이 문제에 관련된 사람들은 React 사용 경험을 통해 제기된 문제를 해결하기 위해 개선 아이디어와 잠재적 API 변경 사항을 탐색하려고 합니다(위에서 설명한 것처럼).

커뮤니티가 API를 발전시키기 위해 혁신을 하고 코어로 롤백하거나 현재 API가 있는 그대로 완벽해야 한다는 말씀이 맞을 수도 있습니다. 리액트 팀.

당신이 있는 그대로의 주장을 하는 이유는 아마도 우리가 현재 API에 대한 이해도가 낮고 거기에 들어간 결정이 라이브러리의 사용자이기 때문일 것입니다. 당신은 당신과 똑같이 경험이 많고 지식이 풍부한 다른 React 팀원들을 끌어들여 우리가 다른 관점을 갖고 있는지 확인하고 훌륭한 솔루션을 제시하거나 이것이 가능한 한 훌륭하다는 합의를 얻을 수 있습니까?

@kmalakoff , React가 엔진과 4개의 바퀴라고 상상해
내가 추천하고 싶은 것은 완전한 차량(완전한 프레임워크)을 얻거나 시간이 지남에 따라 재사용할 수 있는 방식으로 필요한 구성 요소를 구축하는 것입니다.
이 스레드에서 내가 본 것은 엔진에 유압 시스템과 실내등이 없다고 불평하는 엔진 사용자입니다. 내가 느끼는 것은 이러한 기능이 속하지 않는 곳에 이러한 기능을 추가하면 완전히 쓰레기가 될 것입니다.
React는 프레임워크가 아닙니다. 강력한 구성 요소 시스템을 노출하는 diff 기반 렌더링 엔진입니다. 낮은 수준의 최소한의 API를 가지고 있지만 그 위에 말 그대로 무엇이든 구축할 수 있을 만큼 충분히 강력합니다.
내가 뭔가를 명확히 해야 한다고 생각되면 주저하지 말고 이메일을 통해 저에게 연락하십시오. 이 스레드가 튜토리얼이 되는 것을 원하지 않습니다.

@me-andre 나는 우리가 지금 당신의 입장과 당신의 주장을 잘 이해하고 있다고 믿습니다. 감사합니다! API가 이미 얻을 수 있을 만큼 훌륭하다는 것이 옳을 수도 있지만 개선될 가능성도 있습니다.

누군가 API 변경에 대한 사례를 만들 수 있습니까? 예를 들어 다양한 옵션에 대한 비교 분석 제공(componentDidReceiveProps 추가 대 API 병합/단순화 대 변경 없음)

React 팀은 이 문제를 지켜보고 있으며 내부적으로 논의하고 있습니다. 원칙적으로 저는 항상 API 노출 영역을 제거하는 방향으로 기울고 있으므로 @me-andre의 주장에 기댈 수 있습니다. 그러나 우리 팀은 때때로 componentDidReceiveProps 를 "잃어버린 수명 주기 방법"으로 애정 어린 표현으로 언급하며 잠재적으로 추가하는 것에 대해 진지한 논의가 있습니다. 중요한 것은 나쁜 관행을 촉진하지 않고 모범 사례를 가능하게 하는 것입니다.

우리(또는 적어도 나)에게 가장 유용한 것은 사람들이 이 수명 주기 방식을 원하는 이유를 확실히 이해하는 것입니다. 다른 수명 주기 방법에서 충분히 다루지 않는 이 수명 주기에서 무엇을 하려고 합니까? 왜 누군가의 희망이 할 것 UserActions.load(id); 에서 componentDidReceiveProps 대신에 제안 렌더링 내에서의 https://github.com/facebook/react/issues/3279#issuecomment -163875454 (내가 생각할 수있는 이유가 무엇인지 궁금합니다.) props를 기반으로 데이터 로드를 시작하는 것 외에 다른 사용 사례가 있습니까?

@jimfb 나는 componentDidReceiveProps 가 정확히 내가 필요한 것이고 다른 방법은 부적절하다고 생각하지만 내가 틀릴 수 있습니다. 내 사용 사례를 기꺼이 설명하겠습니다.

내 react-router 에 다음과 같은 경로가 있습니다.

    <Route path="/profile/:username" component={ProfilePage} />

외부 소스에서 프로필에 대한 데이터를 가져와야 하고 이를 제대로 수행하려면 componentDidMount 메서드에서 HTTP 요청을 해야 합니다.

불행히도 한 프로필에서 다른 프로필로 이동할 때 React Router는 생성자 메서드나 componentDidMount 메서드를 다시 호출하지 않습니다(물론 이것은 버그일 수 있지만 지금은 아니라고 가정하겠습니다) .

이론적인 componentDidReceiveProps 를 사용하여 이것을 고칠 생각을 했습니다. 불행히도 아직 존재하지 않으며 componentWillReceiveProps 는 내 요구 사항을 충족하지 않습니다.

이것에 대한 모든 포인터는 크게 감사하겠습니다.

내 직감은 componentDidReceiveProps 이 정확히 내가 필요로 하는 것입니다.

@shea256 componentWillReceiveProps 이(가) 귀하의 요구에 부합하지 않는 이유를 자세히 설명해 주시겠습니까?

@shea256 또한 구성 요소가 HTTP 요청을 해야 하는 이유는 무엇입니까? 해당 http 요청에는 무엇이 포함되어 있습니까? 데이터인 경우 데이터 콜백이 반환될 때 구성 요소를 비동기식으로 업데이트하지 않는 이유는 무엇입니까?

@jimfb 일반적인 경우는 prop 변경에 대한 응답으로 무언가를 비동기식으로 로드해야 하는 경우입니다. 여기에는 로드가 발생하고 있음을 나타내는 일부 상태를 설정한 다음 데이터가 로드될 때 해당 상태를 설정하는 작업이 포함됩니다.

새로운 props를 탑재하고 수신하는 것은 모두 동일한 로드 주기를 트리거해야 하므로 componentDidMount 및 componentWillReceiveProps 는 업데이트 기능을 호출하는 위치입니다. render 에는 새로운 소품인지 여부에 대한 정보가 없으며 어쨌든 render의 setState는 no-no입니다.

그래서 로딩을 하는 함수가 하나 있습니다. 하지만 난에 통과해야 props 매개 변수로 조심스럽게 사용하지 this.props 에 대한 최신이 componentWillReceiveProps . 이것은 전달된 props를 사용하는 것을 기억해야 하기 때문에 불가피하게 버그를 유발하거나 변경 사항이 도착할 때 미묘한 one-behind 오류가 발생합니다. 그리고 관련된 모든 메서드의 서명은 props를 전달해야 하므로 더 복잡합니다.

예, 현재 API로 수행할 수 있습니다. 그러나 그것은 React가 일반적으로 피하는 데 매우 능숙한 더 서투르고 오류가 발생하기 쉬운 코드를 유발합니다.

@jimfb routeParam 에서 새 사용자 이름을 가져와야 하고 componentWillReceiveProps 로는 아직 가지고 있지 않습니다.

외부 소스에서 프로필 데이터를 로드하려면 HTTP 요청을 해야 합니다(데이터는 로컬에 저장되지 않음).

그리고 render 메서드에서 구성 요소를 업데이트할 수 있지만 약간 지저분한 느낌이 듭니다.

constructor(props) {
  super(props)

  this.state = {
    id: this.props.routeParams.id,
    profile: {}
  }
}

componentDidMount() {
  this.getProfile(this.state.id)
}

render() {
  if (this.props.routeParams.id !== this.state.id) {
    this.getProfile(this.props.routeParams.id)
  }

  return (
    <div>
      <div className="name">
       {this.state.profile.name}
      </div>
    </div>
  )
}

@grassick 은 다음

저에게 일반적인 경우는 prop 변경에 대한 응답으로 무언가를 비동기식으로 로드해야 하는 경우입니다. 여기에는 로드가 발생하고 있음을 나타내는 일부 상태를 설정한 다음 데이터가 로드될 때 해당 상태를 설정하는 작업이 포함됩니다.

예, 이것은 정확히 제 사용 사례입니다.

새 props를 탑재하고 수신할 때 모두 이 동일한 로드 주기를 트리거해야 하므로 componentDidMount 및 componentWillReceiveProps가 업데이트 기능을 호출하는 위치입니다.

잘했다.

@shea256 대신 componentWillReceiveProps 를 사용하여 이 작업을 수행할 수 없습니까?

constructor(props) {
  super(props)

  this.state = {
    id: this.props.routeParams.id,
    profile: {}
  }
}

componentDidMount() {
  this.getProfile(this.state.id)
}

componentWillReceiveProps(nextProps) {
  let { id } = nextProps.params
  if(id !== this.state.id) {
    this.getProfile(id, (profile) => {
      this.setState({ id: id, profile: profile })
    })
  }
}

render() {
  return (
    <div>
      <div className="name">
       {this.state.profile.name}
      </div>
    </div>
  )
}

@grassick 은 다음

저에게 일반적인 경우는 prop 변경에 대한 응답으로 무언가를 비동기식으로 로드해야 하는 경우입니다. 여기에는 로드가 발생하고 있음을 나타내는 일부 상태를 설정한 다음 데이터가 로드될 때 해당 상태를 설정하는 작업이 포함됩니다.

@grassick 은 다음

render는 그것이 새로운 prop인지 아닌지에 대한 정보를 가지고 있지 않으며 어쨌든 render의 setState는 no-no입니다.

여기에서 간단히 말하십시오. componentDidUpdate 가 초기 렌더링에서 호출되면(이후 렌더링과 함께) 사용 사례가 해결됩니까? props가 변경되었는지 확인하고 모든 데이터를 componentDidUpdate 로드할 수 있습니다. 맞죠? 그리고 렌더링에서 this.state.profileName != this.props.profileName 경우 데이터를 로드하고 있음을 알 수 있습니다. 그 대안이 귀하의 사용 사례에 충분합니까?

소품을 기반으로 데이터를 로드하는 구성 요소를 포함하지 않는 사용 사례가 있습니까?

@calmdev 흠, 나는 당신이 옳다고 믿습니다. 나는 그것을 시도합니다.

@jimfb 아마도 componentDidUpdate 사용해 보았지만 작동하지 않는다고 생각했습니다. 다른 모습을 볼 수 있습니다.

그리고 this.state.profileName != this.props.profileName 완전히 확인할 수 있을 것 같지만 이것도 해킹처럼 보이지 않습니까? 이 시점에서 componentWillReceiveProps(nextProps) 가 작동하면 나는 그것을 선호합니다. 이제 저를 괴롭히는 것은 componentDidMount 와의 대칭성이 없다는 것입니다. componentDidMount 대신 componentWillMount 를 사용할 수 있습니까?

전체 수명 주기가 더 깨끗해질 수 있을 것 같습니다.

@shea256 , 질문이 있습니다... React에 대한 README 읽어 보셨나요?
그렇게 말하는 것이 불편하지만 그렇지 않다면 익숙하지 않은 도구에 대한 새로운 기능을 요청하지 말아야 합니다. 나에게는 그것이... 터무니없이 들린다.
" componentDidMount 대신 componentWillMount 를 사용해도 될까요?"
아니요, 추가 정보에 명시된 대로 구성 요소가 DOM에 도달하기 전에 componentWillMount 가 호출되고 그 후에 componentDidMount 가 호출되기 때문에 불가능합니다. 글쎄, 당신은 확실히 한 방법을 다른 방법으로 바꿀 수 있고 그것은 당신의 코드를 깨뜨릴 것입니다. 여기에 2가지 방법이 있는 이유는 미학이 아닙니다("대칭" 참조). 렌더링하기 전에 준비를 수행하기 위해 하나의 방법이 필요하고 첫 번째 렌더링 후에 일부 초기 DOM 쿼리/조작을 위해 다른 방법이 필요할 수 있기 때문입니다. 그러나 평균적인 React 구성 요소에는 이색적입니다. 일반적으로 DOM에 수동으로 액세스할 필요가 없습니다.
"그리고 this.state.profileName != this.props.profileName을 완전히 확인할 수 있을 것 같지만 이것도 해킹처럼 보이지 않습니까?"
예, 귀하의 전체 접근 방식은 해킹입니다. 그리고 componentDidReceiveProps 가 props 이 변경되었음을 보장한다고 누가 말했습니까? shouldComponentUpdate 를 정의하지 않는 한 아무 것도 그렇게 하지 않습니다.
이것이 바로 React가 작동하는 방식입니다.

@me-andre 참여해 주셔서 감사합니다. 하지만 제 취향에 비해 너무 과격하시네요. 또한 나는 당신이 내 질문을 이해했다고 믿지 않습니다. 저는 componentWillMount 및 componentDidMount 가 하는 일에 대해 잘 알고 있습니다. @jimfb님 의 답변을 기다리겠습니다.

@shea256 ,
"또한 당신이 내 질문을 이해했다고 생각하지 않습니다."
질문에 답할 때 제가 놓친 부분을 지적해 주시겠습니까?
또한 질문하려는 내용을 명확히 해주실 수 있습니까?
또한 우리는 성격이나 취향을 논하기 위해 여기에 있는 것이 아닙니다. 이것은 사적인 대화가 아니며 기술 지원도 아닙니다. 이것은 지식의 일부 영역을 안내해 줄 스택 교환 웹사이트도 아닙니다.
저는 지역 모임과 국제 회의에서 React(뿐만 아니라)에 대해 자주 이야기하며 지식 공유에 매우 개방적입니다. 적절한 시기와 장소에서 말이죠. 당신은 항상 이메일이나 스카이프를 통해 저에게 직접 연락할 수 있습니다.

프로필 데이터 로드 관련 문제. 기능 지향 프레임워크에 고전적인 명령적 접근 방식을 적용하는 문제를 해결하려고 합니다. React의 뷰는 props, state, environment의 함수입니다. function(state, props) { return // whatever you've computed from it } 처럼 (하지만 현실 세계에서는 상황이 약간 더 복잡해집니다. 그렇지 않으면 React가 전혀 존재하지 않을 것입니다). 0.14 순수 기능 구성 요소를 얻지 입력 함수는 render() 입니다.

이것은 render() 부터 쓰기 시작하고 소품이 항상 최신 상태라고 가정하고 props 가 변경되었는지 여부, 몇 번, 어디에서 변경되었는지 상관하지 않는다는 것을 의미합니다 . 당신의 경우는 다음과 같은 방식으로 구현될 수 있습니다:

// profile-view.js

var React = require('react');

module.exports = React.createClass({
    contextTypes: {
        app: React.PropTypes.object.isRequired
        // another option is var app = require('app')
        // or even var profiles = require('stores/profiles')
    },
    componentWillMount() {
        var {app} = this.context; // another option is to require('app')
        app.profiles.addListener('change', this.onStoreChange);
    },
    componentWillUnmount() {
        var {app} = this.context; // another option is to require('app')
        app.profiles.removeChangeListener('change', this.onStoreChange);
    },
    onStoreChange() {
        this.forceUpdate();
    },
    render() {
        var {app} = this.context;
        var profile = app.profiles.read(this.props.routeParams.id);
        if (profile) { // profile's been loaded
            return <div>{profile.name}</div>;
        } else { // not yet
            return <div>Loading...</div>;
        }
    }
});

// profiles-store.js
// app.profiles = new Profiles() on app initialization

var EventEmitter = require('events');
var {inherits} = require('util');

module.exports = Profiles;

function Profiles() {
    this.profiles = {};
}

inherits(Profiles, EventEmitter);

Profiles.prototype.read = function(id) {
    var profile = this.profiles[id];
    if (!profile) {
        $.get(`profiles/${id}`).then(profile => {
            this.profiles[id] = profile;
            this.emit('change');
        });
    }
    return profile;
};

아주 간단합니다.
그리고 componentDidReceiveProps 필요하지 않습니다. componentWillReceiveProps 및 유사한 후크도 필요하지 않습니다. 사소한 경우에 필요하다고 느낀다면 React에서 작업을 수행하는 방법에 대한 이해를 놓치고 있는 것입니다. 그것을 얻으려면 적절한 리소스 를 사용 하고 저장소의 Issues 섹션을 폐기하지 마십시오. 제 입맛에는 좀 과한 감이 있습니다. 남의 시간을 존중하지 않는 것 같기도 하다.

@me-andre 당신이 단지 도움을 주려고 하지만 약간 대립적으로 보일 수 있기 때문에 당신의 언어를 약간 낮추는 것이 가치가 있을 것입니다. 우리는 모든 사람을 환영하는 커뮤니티를 만들고 싶습니다. 우리는 한때 모두 뉴비였습니다. API/디자인에 대한 귀하의 요점 중 일부가 정확하더라도 많은 사람들이 문제를 +1한다는 사실 자체가 뭔가 잘못되었다는 표시이므로 사람들이 무엇을/왜 원하는지 이해하려고 노력해야 합니다. 수명 주기. 문제는 구성 요소(문서)를 올바르게 작성하는 방법을 충분히 전달하지 못하거나 React의 API에 변경이 필요하다는 것입니다. 어느 쪽이든 여기에서 불만/질문/코멘트를 이해하는 것이 좋습니다.

@shea256 this.state.profileName != this.props.profileName 는 내부 상태(구성 요소가 렌더링하는 내용)가 부모가 구성 요소에 렌더링하도록 요청한 내용과 일치하는지 확인합니다. 이것은 거의 "구성 요소가 업데이트 중입니다" 또는 "구성 요소가 최신 상태입니다"의 정의이므로 해킹으로 보지 않습니다. 최소한 "prop이 변경될 때 데이터 업데이트 요청을 실행하고 콜백에서 setstate를 수행"한다는 아이디어보다 더 해킹은 없습니다.

@shea256 분명히 주기로 인해 현재의 수명 componentDidReceiveProps 의 필요성을 이해하려고 합니다.

그리고 누가 componentDidReceiveProps가 props가 변경되었음을 보장한다고 말했습니까?

@me-andre가 여기에 맞습니다. 대부분의 수명 주기 방법은 실제로 무언가가 변경되었음을 보장하지 않습니다. 그들은 단지 무언가가 _아마도_ 변경되었음을 나타냅니다. 이러한 이유로 http 요청을 만드는 것과 같은 작업을 수행하려는 경우 항상 previous === next 인지 확인해야 합니다. 이 스레드의 많은 사람들은 단지 수명 주기 메서드가 실행되었기 때문에 자신의 값이 변경되었다고 가정하는 것 같습니다.

@me-andre는 다음과 같이 썼습니다.

기능 지향 프레임워크에 고전적인 명령적 접근 방식을 적용하는 문제를 해결하려고 합니다.

이것이 사람들이 이 새로운 수명 주기 방법을 원하는 근본 원인일 수 있다고 생각하지만 사람들이 이 방법을 사용하려는 이유/방법을 파악하기 위해 여전히 노력하고 있습니다. 현재 수명 주기 의미 체계가 사람들이 일반적으로 하고 싶어하는 것과 약간 잘못 정렬되어 있을 가능성이 있습니다.

전체: "prop 변경에 대한 응답으로 비동기적으로 데이터 로드" 외에 componentDidReceiveProps 대한 사용 사례가 있습니까?

cc @grassick @iammerrick

@jimfb 내 코드를 검색하고 componentWillReceiveProps 를 사용하여 렌더링에 필요한 생성 비용이 많이 드는 개체를 빌드합니다. 이 경우는 props를 전달해야 하고 코드에서 this.props 를 사용하지 않도록 주의해야 하는 동일한 문제가 있습니다.

@jimfb 는 다음

@me-andre 당신이 단지 도움을 주려고 하지만 약간 대립적으로 보일 수 있기 때문에 당신의 언어를 약간 낮추는 것이 가치가 있을 것입니다. 우리는 모든 사람을 환영하는 커뮤니티를 만들고 싶습니다. 우리는 한때 모두 뉴비였습니다. API/디자인에 대한 귀하의 요점 중 일부가 정확하더라도 많은 사람들이 문제를 +1한다는 사실 자체가 뭔가 잘못되었다는 표시이므로 사람들이 무엇을/왜 원하는지 이해하려고 노력해야 합니다. 수명 주기. 문제는 구성 요소(문서)를 올바르게 작성하는 방법을 충분히 전달하지 못하거나 React의 API에 변경이 필요하다는 것입니다. 어느 쪽이든 여기에서 불만/질문/코멘트를 이해하는 것이 좋습니다.

언급해 주셔서 감사합니다. 환영하는 커뮤니티가 있는지 확인하는 것이 매우 중요하며 귀하와의 커뮤니케이션이 즐거웠습니다.

@jimfb 는 다음

@shea256 this.state.profileName != this.props.profileName은 내부 상태(구성 요소가 렌더링하는 내용)가 부모가 구성 요소에 렌더링하도록 요청한 내용과 일치하는지 확인합니다. 이것은 거의 "구성 요소가 업데이트 중입니다" 또는 "구성 요소가 최신 상태입니다"의 정의이므로 해킹으로 보지 않습니다. 최소한 "prop이 변경될 때 데이터 업데이트 요청을 실행하고 콜백에서 setstate를 수행"한다는 아이디어보다 더 해킹은 없습니다.

예, 이것은 합리적으로 보입니다.

@jimfb 는 다음

@shea256 분명히 주기로 인해 현재의 수명

나는 이것에 매우 동의합니다. 나는 그것에 대한 도움을 받기 위해 내 특정 사용 사례를 게시하지 않았습니다. componentDidReceiveProps 가 유용할 것이라고 생각한 이유에 대한 통찰력을 제공하기 위해 게시했습니다.

나와 분명히 게시한 12명 이상의 다른 사람들은 이와 같은 것을 사용하려는 본능이 있었습니다(즉, 수백 또는 수천 개 더 있을 수 있음을 의미함). 이는 API가 가능한 한 직관적이지 않다는 것을 나타냅니다.

@jimfb 는 다음

@me-andre가 여기에 맞습니다. 대부분의 수명 주기 방법은 실제로 무언가가 변경되었음을 보장하지 않습니다. 그들은 단지 무언가가 변경되었을 수 있음을 나타냅니다. 이러한 이유로 http 요청과 같은 작업을 수행하려는 경우 항상 이전 === 다음인지 확인해야 합니다. 이 스레드의 많은 사람들은 단지 수명 주기 메서드가 실행되었기 때문에 자신의 값이 변경되었다고 가정하는 것 같습니다.

나는 이런 가정을 하지 않는다. 나는 수표를 생략했지만 지금은 하나를 사용하고 있습니다. 그러나 최악의 경우 추가 요청이 트리거됩니다.

@jimfb 는 다음

이것이 사람들이 이 새로운 수명 주기 방법을 원하는 근본 원인일 수 있다고 생각하지만 사람들이 이 방법을 사용하려는 이유/방법을 파악하기 위해 여전히 노력하고 있습니다. 현재 수명 주기 의미 체계가 사람들이 일반적으로 하고 싶어하는 것과 약간 잘못 정렬되어 있을 가능성이 있습니다.

혹시. 나는 이것에 대해 더 생각할 것입니다.

componentDidReceiveProps 는 내가 가진 특정 사용 사례에 도움이 될 것입니다.

ReactRouter 및 Flux 아키텍처를 사용하고 있습니다. 내 구성 요소가 인스턴스화되면 내 상태를 상점의 항목으로 설정합니다. 해당 상점에서 변경 이벤트를 내보내면 동일한 검색 쿼리를 사용하여 상태를 업데이트합니다.

동일한 경로에서 다른 항목 ID로 이동하여 소품이 변경되면 내 상점을 다시 쿼리해야 합니다. 그렇지 않으면 내 구성 요소가 상점의 이전 항목 상태로 멈춥니다.

현재 componentWillReceiveProps 가 호출되면 경로 매개변수가 변경되었는지 확인하고 변경된 경우 updateItemState를 호출합니다. 그러나 props가 실제로 변경되지 않았기 때문에 이제 props를 내 메서드에 전달해야 합니다.

this.updateItemState( nextProps );

updateItemState( props ) {
    props = props || this.props;

    this.setState( {
        item: this.getItemState( props )
    } );
}

getItemState( props ) {
    props = props || this.props;

    return this.ItemStore.get( props.params[ this.paramName ] );
}

단순히 될 것입니다

this.updateItemState();

updateItemState() {
    this.setState( {
        item: this.getItemState()
    } );
}

getItemState() {
    return this.ItemStore.get( this.props.params[ this.paramName ] );
}

나는 이것이 합리적인 사용 사례라고 생각합니다.

@kinnee-gl et al: 업데이트 외에 초기 마운트 후에 componentDidUpdate가 실행되면 사용 사례가 해결됩니까?

@aknnee-gl , Flux를 사용하는 경우 저장소에서 상태를 설정할 필요가 없습니다. 절대 불가능한 경우가 아니면 상태를 한곳에 유지해야 합니다. Flux의 경우 그 장소는 상점 자체입니다. 상점에서 변경 사항을 내보냈을 때 forceUpdate() 그리고 render() read() 상점입니다.

"동일한 경로에서 다른 항목 ID로 이동하여 소품이 변경되면 내 상점을 다시 쿼리해야 합니다. 그렇지 않으면 내 구성 요소가 상점의 이전 항목 상태로 멈춥니다."

절대.

살펴보세요: 상점에서 특정 항목을 렌더링해야 하고 렌더링할 항목은 props 에서 결정합니다. 그것이 귀하의 요구 사항이라면 다음과 같은 방식으로 코드로 표현해야 합니다.

    var item = this.props.store.read(this.props.id);
    return <div>{item.name}</div>;

이것은 당신의 구성 요소이며 그 이상은 아닙니다.
Flux에서 이 기능을 사용하려면 스토어 바인딩/바인딩 해제를 위한 재사용 가능한 구성 요소를 작성할 수 있습니다.

<FluxWrapper store={store} component={Component} id={this.props.routeParams.id} />

var FluxWrapper = React.createClass({
    componentWillMount() {
        this.props.store.addListener('change', this.onStoreChange);
    },
    componentWillUnmount() {
        this.props.store.removeListener('change', this.onStoreChange);
    },
    onStoreChange() {
        this.forceUpdate();
    },
    render() {
        var Component = this.props.component;
        return <Component {...this.props} />;
    }
});

var Component = React.createClass({
    render() {
        var item = this.props.store.read(this.props.id);
        return <div>{item.name}</div>;
    }
});

React를 올바르게 사용하면 구성 요소가 얼마나 작아 질 수 있는지 확인하십시오.

그러나 상점이 무거워 read() render() 마다 상점을 FluxWrapper 와 유사)이거나 원래 read() 메서드를 숨기는 중간 프록시 저장소
이것을 구성이라고 합니다. 컴포지션이 확장 되기 때문에 상속이나 확장 기능보다 컴포지션을 선호해야 합니다.
하나의 구성 요소로 해결하기 어려운 문제가 발생하면 기존 구성 요소에 복잡성을 가하는 대신 2개 이상의 구성 요소를 사용하는 것을 고려하십시오.

@jimfb , 제 어조에 관해: 저는 영어가 모국어가 아니며 정기적으로 말하기 연습도 하지 않기 때문에 가끔 잘못된 단어를 고를 수 있습니다. 감정적으로 어떻게 들리는지 느끼지 못합니다.

흥미로운 접근 방식. 명심하겠습니다. React의 모든 공식 문서에서는 렌더링 기능을 순수하게 유지해야 한다고 말합니다(즉, 렌더링 메서드에서 props 및 state에만 액세스해야 함을 의미합니다). 모든 Flux 예제는 저장소의 설정 상태를 보여줍니다.

@jimfb componentDidUpdate 의 문제점은 props 변경 이외의 다른 이유로 호출된다는 것입니다. 또한 구성 요소가 이미 업데이트될 때까지 기다린 다음 setState를 호출하여 다시 업데이트해야 합니다! 상당히 비효율적인 것 같습니다.

@aknnee-gl componentWillReceiveProps 는 소품 변경 이외의 이유로 호출될 수도 있으므로(https://github.com/facebook/react/issues/3279#issuecomment-164713518 참조) 다음을 확인해야 합니다. prop이 실제로 변경된 경우(선택한 수명 주기에 관계없이). 또한 실제로 비동기식 데이터를 수행하는 경우 콜백이 실행되기 전에 다음 이벤트 루프를 기다려야 합니다. 렌더 기능 맞죠?

@jimfb 사실, prop이 참조하는 아이템이 이미 스토어에 있다면 다시 렌더링할 필요가 없습니다. 아직 스토어에 없는 경우 로딩 화면을 표시할 수 있습니다. 따라서 두 번 렌더링하는 것은 여전히 ​​의미가 없습니다. 무슨 말인지 알겠어요.

@me-andre 렌더링하는 동안 상점에서 읽는 방식이 정말 마음에 듭니다. 코드를 단순화하는 것 같습니다. 하지만 그렇게 하면 효율성이 떨어질까 걱정됩니다. shouldComponentUpdate를 통해 업데이트를 제어하는 ​​기능을 잃게 되며 언급한 추가 FluxWrapper 구성 요소를 추가해야 합니다. 그것에 대한 생각이 있습니까?

나는 토론을 모니터링하고 있으며 세 번째 옵션을 다시 표면화하고 싶습니다. (1) API는 있는 그대로 훌륭하고, (2) componentDidReceiveProps가 필요하고, (3) 더 간단한 API가 있을 수 있습니다.

(1)과 (2)의 솔루션 공간으로 논의를 제한하기보다 API를 더 심층적으로 변경하여 브레인스토밍하여 이 문제로 인해 제기된 근본적인 요구를 해결할 수 있는지 확인하는 기회로 문제를 보고 있습니다.

단순화된 API는 다음 원칙을 기반으로 할 수 있습니다.

(A) 코드 구조 단순화 / 상용구 감소
(B) props(입력)를 state(내부)와 분리하여 유지

(A)의 주된 이유는 내가 부가가치가 없는 상용구를 작성하고 있다는 사실을 알게 되었기 때문입니다. 예시:

componentWillMount() { this.actuallyCheckThePropsAndMaybeDoSomething(); }
componentWillReceiveProps(nextProps) { this.actuallyCheckThePropsAndMaybeDoSomething(nextProps); }

actuallyCheckThePropsAndMaybeDoSomething(props) {
  props = props || this.props;

  let relatedProps1 = _.pick(props, KEYS1);
  if (!shallowEqual(this.relatedProps1, relatedProps1) { // changed
   this.relatedProps1 = relatedProps1;

   // do something
  }

  let relatedProps2 = _.pick(props, KEYS2);
  if (!shallowEqual(this.relatedProps1, relatedProps2) { // changed
   this.relatedProps2 = relatedProps2;

   // do something else
  }
}

나는 오히려 다음을 수행하고 처음 대 변경되는 별도의 코드 경로를 갖지 않을 것입니다.

propsUpdated(prevProps) {
  if (!shallowEqual(_.pick(prevProps || {}, KEYS1), _.pick(this.props, KEYS1)) { // changed
   // do something
  }

  if (!shallowEqual(_.pick(prevProps || {}, KEYS2), _.pick(this.props, KEYS2)) { // changed
   // do something
  }
}

(B)의 경우 componentDidUpdate의 주요 문제점은 props(inputs)와 (internal) state 모두에 대해 호출되기 때문에 속성 변경으로 인해 state를 설정하면 반복되는 메서드 호출을 트리거할 수 있다는 것입니다. 이러한 코드 경로는 props가 외부에서 제공되고 상태가 내부에서 설정되기 때문에 분리될수록 더 나은 것 같습니다. 나는 상용구를 줄이기 위해 componentDidUpdate를 사용하여 updated(prevProps, prevState) (더 적은 수명 주기 메서드가 더 짧은 명명을 허용할 수 있기 때문에 componentDidUpdate의 단순화된 이름)의 네 번째 가능성을 시도/고려했지만 잠재적인 중복 두 번째 가능성에 약간 불만족스럽습니다. 업데이트 호출과 그 논리는 실제로 매우 독립적인 것으로 보입니다.

디자인 원칙부터 시작하여(더 있을 것이라고 확신합니다!), propsUpdated 및 stateUpdated 라인에 따른 것이 이 토론의 잠재적인 세 번째 옵션이 될 수 있는지 궁금합니다. ?

@kmalakoff props가 변경되었는지/변경되지 않았는지 확실하게 말할 수 없기 때문에 props가 변경되었는지 항상 확인해야 합니다(Javascript에는 값 유형이 없고 가변성이 있기 때문에).

그 점에서 아마도 shouldComponentUpdate를 호출하여 propsDidChange를 호출해야 하는지 여부를 알릴 수 있습니다. 별개의 문제지만.

@jimfb 는 귀하가 언급하는 언어 제한이 무엇이며 일반적으로 API를 단순화하는 것과 어떤 관련이 있는지 정확히

나는 그가 this.props === nextProps 인지 확인하는 내장된 빠른 방법이 없다는 것을 의미한다고 생각합니다. 왜냐하면 그것들이 두 개의 개별 객체일 수도 있고 아닐 수도 있기 때문입니다.

{ a: 1 } === { a: 1 } 는 두 개의 개별 개체이기 때문에 false를 반환하지만

var a = { a: 1 };
var b = a;
a === b

실제로 둘 다 동일한 객체에 대한 참조이기 때문에 true를 산출합니다.

각 속성이 같은지 재귀적으로 확인할 수 있지만 이는 매우 느릴 수 있습니다. 그렇기 때문에 shouldComponentUpdate 를 구현하는 것은 우리에게 달려 있습니다.

@kmalakoff 이 스레드를 https://gist.github.com/jimfb/9ef9b46741efbb949744

TLDR: @akinnee-gl의 설명이 정확합니다(감사합니다!). prop으로 전달된 콜백 함수를 재귀적으로 확인할 방법이 없기 때문에 (우리가 원하고 성능이 문제가 아니더라도) 항상 재귀 검사를 수행할 수 없다는 사소한 수정으로.

그래도 이 스레드를 주제로 유지합시다 :P.

둘 다 감사합니다! 흠, API를 단순화하는 것이 이 문제를 해결하기 위한 옵션이 아닌 이유에 대해 아직 완전히 명확하지 않습니다. 나는 요점 에 의견을 추가 할 것입니다 ...

더 넓은 범위의 솔루션에 참여하고 싶은 사람이 있다면 거기에 참여하십시오!

@jimfb @calmdev 귀하의 제안을 시도했고 이제 componentDidReceiveProps 가 실제로 새로운 것을 추가하지 않고 추가 기능으로 추가되어서는 안 되는 이유를 완전히 이해했습니다. 이전에는 당신의 말을 믿었지만 이제는 왜 이것이 사실인지 직관적으로 이해가 됩니다.

이 깨달음을 얻은 방법을 설명하기 위해 최신 코드를 공유하고 싶습니다. 아마도 이것은 다른 사람들에게도 도움이 될 것입니다.

내 프로필 페이지 구성 요소를 살펴보십시오.

class ProfilePage extends Component {
  static propTypes = {
    fetchCurrentProfile: PropTypes.func.isRequired,
    currentProfile: PropTypes.object.isRequired
  }

  constructor(props) {
    super(props)
    this.state = { currentProfile: {} }
  }

  componentHasNewRouteParams(routeParams) {
    this.props.fetchCurrentProfile(routeParams.id)
  }

  componentWillMount() {
    this.componentHasNewRouteParams(this.props.routeParams)
  }

  componentWillReceiveProps(nextProps) {
    if (nextProps.routeParams.id !== this.props.routeParams.id) {
      this.componentHasNewRouteParams(nextProps.routeParams)
    }
    this.setState({
      currentProfile: nextProps.currentProfile
    })
  }

  render() {
    var profile = this.state.currentProfile
    return (
      <div>
        <h1>{ profile.name ? profile.name : null }</h1>
      </div>
    )
  }
}

구성 요소가 탑재되면 프로필 데이터가 없으며 외부 소스에서 프로필을 로드해야 합니다.

그래서... 외부 소스에서 데이터를 가져오는 fetchCurrentProfile 함수( componentHasNewIdProp 래핑됨)를 호출한 다음 업데이트 작업을 Redux에 전달합니다. 감속기는 이 작업을 수신하고 애플리케이션 상태를 업데이트한 다음 ProfilePage 구성 요소에 대한 props를 업데이트합니다.

이제 props가 업데이트되었으므로 componentWillReceiveProps 함수가 호출됩니다. 그러나 우리는 prop change 이벤트의 컨텍스트를 알지 못하기 때문에 어떤 props(있는 경우)가 변경되었는지 알아내야 합니다. ID가 동일하므로 fetchCurrentProfile 다시 호출할 필요가 없습니다. 그런 다음 구성 요소가 새 프로필 데이터로 다시 렌더링할 수 있도록 state.currentProfile 업데이트합니다. 이때 상태를 업데이트하기 전에 props.currentProfile 이 변경되었는지 확인할 수 있지만 이는 비용이 많이 드는 작업이 아니므로 확인해도 상관 없습니다.

그런 다음... 한 프로필에서 다른 프로필로 이동하려고 한다고 가정해 보겠습니다. 링크를 클릭하면 라우터가 경로 변경을 트리거합니다. 이제 새로운 경로 매개변수가 있고 componentWillReceiveProps 함수가 트리거됩니다. id 이 변경되었음을 확인하고 fetchCurrentProfile 다시 호출합니다( componentHasNewIdProp ).

새 가져오기가 돌아와서 redux 작업을 전달하면 currentProfile 소품이 다시 업데이트되고 상태가 업데이트되고 구성 요소가 새 보기로 다시 렌더링됩니다.

이 예제는 구성 요소가 마운트될 때와 구성 요소가 새 props를 수신할 때 다른 동작이 필요한 방법을 보여줍니다. 또한 후자의 경우 변경 사항에 대해 props를 확인하는 방법과 특정 props 변경 시에만 특정 함수를 호출해야 하는 방법을 보여줍니다.

돌이켜보면 본질적으로 내가 원했던 것은 routeParams 변경되었을 때만 업데이트되는 기능이었습니다. 그러나 기존 기능으로 원하는 모든 작업을 수행할 수 있고 수명 주기를 복잡하게 만들고 싶지 않기 때문에 다른 기능을 추가할 필요가 없습니다.

그러나 여기서 도움이 될 수 있는 것은 수명 주기, 작업 예제 등에 대한 추가 문서입니다.

도와주셔서 감사합니다. 여기서 제가 잘못 알고 있는 것이 있으면 알려주세요. 앞으로 이 스레드를 우연히 발견하는 모든 사람들에게 이것이 도움이 되기를 바랍니다.

@shea256 귀하의 예는 새로운 API 관점 없이 필요한 것을 달성할 수 있다는 점에서 새로운 API가 필요하지 않은 합리적인 사례인 것 같습니다.

https://gist.github.com/jimfb/9ef9b46741efbb949744 에서 더 많은 생각을 요약했지만 여전히 적은 코드를 작성하기 위해 API를 간소화할 수 있어야 한다고 생각합니다...

API를 사용하여 동일한 기능을 작성할 수 있지만 상용구가 적다고 상상해 보십시오.

class ProfilePage extends Component {
  static propTypes = {
    fetchCurrentProfile: PropTypes.func.isRequired,
    currentProfile: PropTypes.object.isRequired
  }
  state = {currentProfile: {}}; // not material to example (babel-stage-1)

  // called both on init and update
  willReceiveProps(nextProps) {
    if (!this.props || (this.props.routeParams.id !== nextProps.routeParams.id)
      nextProps.fetchCurrentProfile(nextProps.routeParams.id)
  }

  render() {
    var profile = this.props.currentProfile;
    return (
      <div>
        <h1>{ profile.name ? profile.name : null }</h1>
      </div>
    )
  }
}

내가 고려되기를 바라는 아이디어는 코드 경로와 상용구의 수를 줄이기 위해 API 표면적을 줄이는 것입니다. 다른 관점에서 보면 새로운 길을 열 수 있을 때 무언가를 추가해 달라는 초기 요청에 토론이 고정 되어 있는지 궁금합니다.

이것은 하나의 옵션일 뿐입니다(내 선호도는 receiveProps(prevProps)입니다. 이상적으로는 this.props를 사용할 수 있는 prop 관련 메서드가 하나만 있기 때문입니다). 그러나 중요한 부분은 초기화를 위한 하나의 코드 경로가 있다는 것입니다. 다른 API 서명을 사용하는 다른 코드 경로가 아닌 구성 요소 및 모든 소품 변경. 사람들이 더 나은 데 동의하는 솔루션이 무엇이든 상관없습니다.

상용구를 줄이는 것이 이 문제가 달성할 수 있기를 바라는 것이며(내 요구/문제를 명확히 하기 위해!) 해당 솔루션이 어떻게 생겼는지에 대해 좀 더 광범위하게 브레인스토밍하고 싶습니다(API 제거, ES6이 널리 사용 가능하고 구성 요소가 앞으로 나아갈 것 같기 때문에 메서드 이름을 크게 줄이는 등).

@aknnee-gl , 여러 가지 작은 구성 요소로 구성된 응용 프로그램을 갖는 것이 몇 가지 이유 때문에 몇 가지 무거운 구성 요소보다 훨씬 낫습니다.

1. 이 접근 방식은 "단일 책임 원칙"과 연결됩니다.
2. 어떤 구성 요소가 어떤 작업을 수행하는지 명확하게 볼 수 있습니다.
3. 래핑하여 기능을 쉽게 구성하고 구성 요소를 확장할 수 있습니다.
4. 메서드와 속성이 충돌하지 않습니다.
5. 하나의 구성 요소가 하나의 기능을 캡슐화하기 때문에 기능을 확장하는 것이 더 쉽습니다.

각 렌더에서 스토어에서 읽는 것이 비효율적일 수 있다는 귀하의 통지와 관련하여 캐싱을 위한 미들웨어 구성 요소를 구현하는 방법에 대한 기본 아이디어를 보여주는 요지를 만들었습니다. https://gist.github.com/me-andre/0ca8b80239cd4624e6fc

개선된 API로 이어질 수 있는 원칙/목표를 다시 한 번 확인했습니다.

(A) 코드 구조 단순화 / 상용구 감소
(B) props(입력)를 state(내부)와 분리하여 유지
(C) 구성 요소의 렌더링을 제어하는 ​​메서드 허용
(D) 컴포넌트 서브클래싱의 가정을 기반으로 메소드 명명 단순화
(E) 초기화와 변경 모두에 대해 props 메소드의 수를 하나로 줄입니다.
(F) props 메소드에는 최신 값이 있는 this.props가 있어야 합니다.

요지에 그들 중 일부에 대한 설명이 있습니다.

@kmalakoff 요지에 따르면 이러한 문제의 범위를 늘리지 맙시다. 문제는 이미 충분히 복잡하며 대화를 완전한 API 재설계로 전환하는 것은 다루기 쉽지 않을 것입니다. 이러한 문제에 대해 계속 생각하는 것을 환영하지만 이 스레드를 주제로 유지하십시오.

@kmalakoff 귀하가 언급한 많은 요점은 다른 문제의 주제입니다. 예를 들어 (D)는 https://github.com/reactjs/react-future/issues/40#issuecomment -142442124 및 https://github.com/reactjs/react-future/issues/40#issuecomment 에 의해 답변됩니다. 153440651. 그것들은 그 토론을 하기에 적절한 스레드입니다. 더 일반적/전체론적 디자인/API 토론을 찾고 있다면 올바른 매체는 아마도 https://discuss.reactjs.org/ 일 것입니다.

@jimfb 당신이 이것을 요점으로 옮기고 실제로 이 분석 라인이 주제에서

제 말을 들어주세요... 상용구를 줄이는 것은 이 문제 의 수명 주기 방법으로 해결할 수 있는 문제입니다.

현재 API가 우리가 원하는 것보다 더 많은 상용구를 권장하기 때문에 사람들이 이 수명 주기 방식에 관심을 갖는 이유의 중요한 부분이 될 수도 있다고 생각합니다.

즉, API 개선 사항을 분리하려고 노력하고 예를 들어 이 문제의 props와 관련된 API 개선과 관련된 솔루션 공간 탐색에만 집중할 수 있습니다.

@kmalakoff 스레드의 주제는 제목과 첫 번째 게시물로 정의됩니다. 제목은 componentDidReceiveProps Please 아니라 lots of general ways to reduce boilerplate 입니다. 이 스레드는 특히 매우 구체적인 수명 주기 방법의 도입을 통해 상용구를 줄이는 것에 관한 것입니다. 다른 문제에서 이미 논의되고 있는 추가 주제(예: 모든 기능의 이름 바꾸기)를 도입하지 않고 그 논의만으로도 이미 충분히 미묘한 차이가 있습니다.

귀하의 요점은 소중하며 토론을 하는 것이 좋습니다. github 스레드가 당면한 주제에 집중하도록 하고 싶기 때문에 다른 스레드로 옮기십시오. 그렇지 않으면 토론을 추적/관리하기가 너무 어렵습니다. 당신이 제기한 대부분의 주제에 대한 스레드가 존재합니다.

@jimfb 사람들이 componentDidReceiveProps 요구하는 이유는 무엇입니까? 제가 관심을 갖는 이유는 props 와 관련된 상용구 를

당신은 문제와 사용 사례를 요청했고, 저는 이것을 문제로 언급했고 위의 사용 사례(@shea256에 응답)를 보여주었습니다. 이 사용 사례는 주제와 범위 내에서 그리고 내 관점에서 문제 해결에 중요한 것으로 보입니다. 이 문제.

일반적인 API 문제/개선 사항으로 범위를 확장하는 것을 보류하는 데 동의했습니다. 약속합니다! :눈짓:

참고: 이전에 언급했듯이 이 문제에 대한 사고 실험을 시작한 이유는 주장이 너무 협소하게 초점이 맞춰져 있는 것처럼 보였기 때문입니다(예: 현재 API로 필요한 모든 것을 이미 수행할 수 있음). 문제. 아시다시피 때때로 한발 물러서서 초점을 맞추고 다른 각도에서 보고 가정을 다시 검토하고 요청 뒤에 있는 근본적인 이유를 조사하는 등 문제에 대한 최상의 솔루션을 찾기 위해 반복해야 합니다. 바라건대, 제가 이 문제에 주의를 기울이는 데 도움이 되었기를 바랍니다. 제 참여는 이 문제를 만족스럽게 해결하는 데 도움이 될 것입니다! (물론, 나는 또한 React API가 더 사용하기 쉽게 진화하고 다른 곳에서 논의를 계속하기를 희망합니다...링크 주셔서 감사합니다)

@kmalakoff , ok, 상용구를 줄이려면 재사용 가능한 클래스나 다른 구성 요소를 하위 분류하거나 구성하는 구성 요소를 만들면 됩니다. 아무도 앱의 모든 구성 요소에 대해 공통 메서드를 정의하는 것을 막지 못합니다. React는 뛰어난 확장성을 제공합니다. 구성 요소를 객체, 함수 또는 클래스로 정의할 수 있습니다. 서브클래싱, 믹스인 또는 팩토리를 통해 구성요소를 확장할 수 있습니다.

@me-andre 이 문제가 API 개선으로 이어지지 않는 경우 절대적으로 옵션입니다.

이 문제는 API를 개선하기 위해 API를 변경하려는 바람에 대한 토론을 촉진하기 위해 제기되었습니다. 클라이언트 코드에서 대안 탐색을 확실히 고려해야 하지만 API를 변경해야 하는 강력한 경우가 있는 경우 이러한 종류의 해결 방법은 필요하지 않습니다. 반론을 제기하려면 개선된 API가 무엇인지에 대한 사례도 만든 다음 현재 API와 비교하여 평가해야 합니다.

예를 들어, 커스텀 슈퍼클래스를 정의하지 않고 현재 API가 상용구를 줄이는 방식으로 사용될 수 있음을 입증하려는 경우(예: API를 잘못 사용하거나 현재 API에 다음을 달성하는 데 사용할 수 있는 기능이 있습니다. 유사한 수준의 상용구 감소 등) 또는 개선이 불가능한 이유(예: API 개선 옵션에서 지원되지 않는 주요 사용 사례가 있기 때문에 일반적인 솔루션이 존재하지 않음) 등을 만들 수 있습니다. API가 그 자체로 좋은 경우입니다.

API가 기본 및 공통 제어 흐름 패턴에 대한 사용자 지정 슈퍼클래스를 작성하도록 요구하는 경우 API를 개선해야 하는 경우가 있다는 주장을 강화합니다.

궁금합니다. 마운트하기 전에 componentWillReceiveProps 실행되지 않는 이유는 무엇입니까? 생각해보면 컴포넌트가 초기화될 때 실제로 props를 받는 것입니다. 단지 새로운 props를 받지 못할 뿐입니다.

새로운 props를 수신할 때만(초기 prop 수신이 아닌) 무언가를 트리거하려는 사용 사례는 무엇입니까?

나는 여기서 명백한 것을 놓칠 수 있지만 다양한 당사자의 관점을 조화시키려고 노력합니다.

어쨌든 componentWillReceiveNewProps 가 어떤 경우에 중요했다면 들어오는 소품을 확인하여 수정된 componentWillReceiveProps 로 시뮬레이션할 수 있습니다.

@kmalakoff componentWillReceiveProps 가 처음으로 트리거되면 API 단순화에 대한 표준을 충족합니까?

componentWillReceiveProps 마운트 시 트리거되지 않는 것은 사람들이 componentDidReceiveProps 요구하는 이유가 아닙니다. 사람들은 요구하고있다 componentDidReceiveProps 는 액세스에 자신의 모든 방법을 썼다 때문에 this.props . 때 componentWillReceiveProps 호출되면 nextProps 통과되지만, this.props 통과하는 우리가 가진 의미, 아직 변경되지 않은 nextProps 에 대한 응답으로 호출되는 모든 방법으로 componentWillReceiveProps , 그대로 두는 대신. 우리는 props = props || this.props 톤과 우리가 호출하는 모든 함수에 props 를 전달합니다.

@shea256 좋은 점. 초기화와 변경을 위한 다른 코드 경로를 갖는 것은 prop 상용구의 근본 원인 중 하나입니다. 다른 근본 원인은 @kinnee-gl이 지적하는 것과 같은 소품을 처리하기 위해 다른 서명을 사용하는 것입니다.

이것이 실제로 prop 상용구를 더 줄이는 더 나은 솔루션이 있을 수 있기 때문에 고려 중인 솔루션 공간을 확장하려고 하는 이유입니다(예: init 호출).

나는 우리가 더 많은 것을 얻을 수 있기를 바랍니다:

새 후크 이전

componentWillMount() {
  this.setup(this.props.id);
}

componentWillReceiveProps(next) {
  this.setup(next.id);
}

setup(id) {
  UserActions.load(id);
}

New Hook 이후(개정)

componentDidReceiveProps(prevProps) {
  UserActions.load(this.props.id);
}

또는 UserActions.load가 현재 로드된 ID를 확인할 수 없는 경우:

componentDidReceiveProps(prevProps) {
  if (!prevProps || (prevProps.id !== this.props.id))
    UserActions.load(this.props.id);
}

@kmalakoff , 내가 말하는 것은 API 개선이 지금 당장 절대적으로 가능하다는 것입니다. 자신만의 구성 요소 공장을 만든 다음 사용 사례 샘플과 함께 우리와 공유할 수 있습니다. 이렇게 하면 제안과 근거가 백 배 더 명확해집니다. 모든 수명 주기 지점에는 이미 적절한 콜백이 있으므로 모든 수명 주기 지점/구성 요소 상태에서 새 메서드를 도입할 수 있습니다. 이벤트 이미터를 구성 요소에 혼합하고 상태 변경을 위해 여러 핸들러를 연결할 수도 있습니다.

@shea256 , componentWillReceiveProps 가 첫 번째 렌더링 전에 트리거되지 않는 한 가지 가능한 이유는 그 당시 this.props 와 같은 것이 없기 때문입니다. componentWillReceiveProps 에서 일반적으로 하는 일은 this.props[propName] 와 newProps[propName] 입니다. 첫 번째 렌더링 전에 메서드를 트리거하면 this.props 존재 여부도 확인해야 합니다. 게다가 전체 컴포넌트는 초기 렌더링 전에 props 를 수신할 때 완전히 초기화되지 않으며 state 조차 없습니다.

@kmalakoff , setup 또는 유사한 해킹이 필요하지 않은 방식으로 React 구성 요소를 구성하는 방법을 보여주는 코드 샘플을 두 번 게시했습니다. React와 통합되도록 코드를 조정하는 대신 React 구성 요소의 동작을 변경하려고 여전히 노력하는 이유를 말씀해 주시겠습니까? 내 샘플이 귀하의 사용 사례에 적합하지 않은 부분을 지적하면 좋을 것입니다.

@aknnee-gl , 업데이트 시 this.props 에 액세스하는 새로운 방법을 도입하지 않는 이유는 render() 라고 하는 그러한 방법이 있기 때문입니다. shouldComponentUpdate() 확인한 후에도 호출됩니다. 일반적으로 this.props !== newProps 또는 _.isEqual(this.props, newProps) 등을 수행하는 곳입니다.
일부 설정을 위해 별도의 메서드가 필요하다고 생각되면 React 구성 요소를 하위 클래스로 만들고 다음 render() 메서드를 정의하지 않는 것이 좋습니다.

this.setup(this.props);
return this._render();

나는 그것이 React 생태계의 일을 어떻게 단순화하는지 알지 못하지만 그것이 당신이 계속 요청하는 것입니다.

@me-andre 이 문제의 전제는 현재 API로 원하는 것을 달성할 수 없거나 클라이언트 코드에서 현재 API를 해결할 수 없다는 것이 아닙니다. 이 문제의 전제는 현재 React API가 차선책이며 개선이 필요하다는 것입니다 . 예를 들어, 최적의 API가 어떻게 보일지에 대한 원칙을 생각해 낸다면(위에서 시도한 것처럼) 현재 React API는 여러 영역에서 차선책/결핍이기 때문에 중간 수준 범위에서 점수를 매길 것입니다.

불행히도 클라이언트 코드에서 React API를 해결하는 방법을 제공하는 것은 문제의 근본 원인을 해결하지 못하고, 근본적인 문제를 해결하는 것에서 논쟁을 옮기고, React API를 개선하기 위한 잠재적 솔루션에 대한 논쟁으로 이어지지 않습니다.

요컨대, 프로덕션에 많은 React 앱이 있으므로 모범 사례가 블로그 게시물에 유용할 수 있기 때문에 이미 저에게 효과적인 해결 방법이 있습니다. 이 문제의 진정한 목적에 대한 실제 토론: React API를 개선하는 방법(이 문제에서는 소품 사용 사례 및 상용구로 제한됨).

React 1.0은 중간이 아닌 상단을 목표로 해야 합니다. 주요 버전 증가는 이전 버전과의 호환성을 깨뜨릴 수 있으므로 지난 몇 년 동안 0.x 버전을 사용하면서 배운 것을 기반으로 가능한 최상의 API를 찾아 보겠습니다.

(참고: 사람들이 현재 API에 대해 배우기 위해 여기에 오는 것이 아니라 API에 대한 개선 사항을 찾고/희망하기 때문에 원하는 만큼 귀하의 예제에 참여하지 않을 수 있다고 생각합니다. 좋은 의도로 인식될 수 있지만 약간 잘못 정렬됨)

사람들이 현재 API에 대해 배우기 위해 여기에 오는 것이 아니라 API에 대한 개선을 찾고/희망하기 때문에 기대만큼 귀하의 예제에 참여하지 않을 수 있다고 생각합니다.

네, API 개선 제안을 가지고 오셨지만 "React 모범 사례"에서 너무 멀리 떨어진 코드를 보여주셨습니다. 어떤 것들은 최악의 관행처럼 보입니다. 그런 다음 "그것이 변화의 이유입니다"라고 말합니다. 예, 이것이 변경의 이유이지만 React 코드베이스에는 없습니다.
React와 잘 작동하도록 코드를 재구성하지만 적절한 사용법 쇼케이스를 무시하고 계속 주장하는 방법을 보여줍니다. 건설적인 논쟁은 아닌 것 같습니다.

불행히도 클라이언트 코드에서 React API를 해결하는 방법을 제공하는 것은 문제의 근본 원인을 해결하지 못합니다.

해결 방법은 아니지만 일반적인 방법인 상위 수준 API로 하위 수준 API를 래핑하는 경우. 많은 훌륭한 프레임워크가 이 아이디어를 따릅니다.
내가 계속 말하고 있는 것은 당신이 사용하고 우리와 공유하고 싶은 것으로 기존의 못생긴 API를 포장한다는 것입니다. 사용 사례와 더 좋아진 이유에 대한 설명과 함께 놀랍습니다.
다시 말하지만, 나는 당신이 그렇게하지 않는 이유를 알지 못합니다. 당신이 말하는 것이 일반적인 문제라면 많은 사람들에게 큰 도움이 될 것이기 때문입니다.

프로덕션에 React 앱이 많이 있으므로 모범 사례는 블로그 게시물에 유용할 수 있지만 이 문제에서 토론의 한 줄로 사용하면 실제 토론에서 멀어질 뿐입니다.

API를 설계/설계할 때 일반적으로 하는 일은 문제를 예측하고 사용 사례에 대한 가설을 세우는 것입니다. 사람들이 가설을 세우는 이유는 이상을 찾기 위해 현실 세계에서 자신을 추상화하려고 하기 때문이 아닙니다. 경험이 부족할 뿐입니다. "미리" 경험을 얻을 수는 없습니다.

당신은 그런 경험이 있고 실제 문제를 보았고 공유할 수 있는 몇 가지 해결 방법이 있다고 말합니다. 이것이 바로 이 논쟁을 "실제" 및 "효과적인" 것으로 바꿀 수 있는 것입니다. React 자체는 실제 문제와 도전을 기반으로 구축되었습니다. 그래서 "hello world를 3줄로 작성하는 방법"뿐만 아니라 실제 아키텍처 문제를 해결합니다.

@me-andre 나는 당신과 당신의 주장이 분명하다고 들었습니다.

내 주장의 핵심은 현재 React API 사용에 대한 우리의 집단적 경험을 기반으로 더 나은 원칙을 수립하고 몇 가지 근본적인 방식으로 API를 변경할 수 있는 비 독단적 솔루션을 포함하는 토론을 열면 우리는 할 수 있고 해야 한다는 것입니다. 지금보다 더 나은 React API를 만들 수 있는 기회를 잡으세요. 개선의 여지가 있을 때 우리의 월계관에 안주하지 맙시다!

props에 대한 현재 React API를 어떻게 평가하시겠습니까? (글자 등급을 사용한다고 가정해 봅시다: F에서 A+까지), 왜, A+ 미만이면 개선하기 위해 무엇을 하시겠습니까?

@me-andre 순위와 분석을 준비할 기회가 있었나요? 현재 API의 강점, 약점 및 기회가 무엇이라고 생각하는지 듣고 싶습니다.

+1

+1 제발

해결 방법이 있습니까? ComponentDidReceiveProps가 필요합니다

나는 1년 전에 이 문제를 만들었고 그 이후로 매일 React를 사용하고 있습니다. 더 이상 API 증가를 정당화하는 componentDidReceiveProps에 대한 사용 사례가 없다고 생각합니다.

@AlexCppns 당신이하려는 것은 무엇입니까?

@iammerrick , 사실 괜찮습니다. componentWillReceiveProps가 사용되는 방식을 잘못 이해했습니다.

관련 토론: https://github.com/facebook/react/issues/7678

나는 이것을 몇 번 만났고 결국 한 일은 다음과 같습니다.

componentWillReceiveProps(nextProps) {
  if (this.props.foo !== nextProps.foo) this.needsUpdate = true;
}
componentDidUpdate() {
  if (this.needsUpdate) {
    this.needsUpdate = false;
    // update the dom
  }
}

나쁘지 않아.

@brrigand , 플래그가 필요하지 않습니다. componentDidUpdate() 내에서 소품을 비교할 수 있습니다.

componentDidUpdate(prevProps) {
    let needsUpdate = prevProps.foo !== this.props.foo;
    // ...whatever
}

또한 솔루션은 shouldComponentUpdate() 의해 쉽게 손상될 수 있으며, 이는 다시 렌더링을 방지할 수 있습니다.

오 멋지네요, 감사합니다!

@jimfb 아래에 동기 사용 사례가 있다고 생각합니다. 나는 componetDidReceiveProps 가 이것에 완벽했을 것이라고 생각합니다.

  componentDidMount() {
    this._selectAll()
  }

  componentDidUpdate(prevProps) {
    let shouldUpdateSelected = (prevProps.recordTypeFilter !== this.props.recordTypeFilter) ||
      (prevProps.statusFilter !== this.props.statusFilter) ||
      (prevProps.list !== this.props.list)

    if (shouldUpdateSelected) { this._selectAll() }
  }

  _selectAll() {
    this.setState({ selectedIds: this._getFilteredOrders().map((order) => ( order.id )) })
  }

  _getFilteredOrders() {
    let filteredOrders = this.props.list

    // recordTypeFilter
    let recordTypeFilter = this.props.recordTypeFilter
    filteredOrders = _.filter(filteredOrders, (order) => {
        // somelogic
    })

    // statusFilter
    let statusFilter = this.props.statusFilter
    filteredOrders = _.filter(filteredOrders, (order) => {
        // somelogic
    })

    return filteredOrders
  }

@chanakasan , 귀하의 예제에는 귀하의 예제를 이해하고 더 나은 솔루션을 제안하는 데 필수적인 render() 메소드가 없습니다.
둘째, 코드가 일부 사용자 지정 비즈니스 논리에 연결되어 있으며 읽기가 쉽지 않습니다. 주저하지 말고 다른 사람에게 복사하여 붙여넣기를 하지 말고 설명하십시오.
그러나 귀하의 예를 읽었으며 다음과 같은 생각을 공유하고 싶습니다.

1. 이것은 componentDidUpdate 아니라 componentWillReceiveProps 의 사용 사례입니다. componentWillReceiveProps 전환하면 동일한 논리를 유지하면서 구성 요소가 두 배 적게 다시 렌더링됩니다. 이 토론을 떠난 지 1년이 지난 후에도 DOM 변경에 대한 반응을 제외하고는 componentDidUpdate 대한 사용 사례가 전혀 없습니다.
2. 그러나 this.state.selectedIds 가 실제로 상태가 아니기 때문에 후크를 전혀 피하고 모든 논리를 render() 메서드로 이동하거나 상태 비저장 구성 요소로 마이그레이션하는 것이 훨씬 좋습니다. 순전히 소품에서 계산됩니다.

안녕하세요 @me-andre, 시간을 내어 답장을 보내주셔서 감사합니다. 나는 이 페이지의 토론을 읽었고 그것에 참여해주셔서 감사합니다.

예, componentDidReceiveProps 는 필요하지 않지만 이것이 없으면 상황이 신비로워 보입니다.
componentWillReceiveProps 사용한다면 your component would re-render twice as less 라고 말씀하셨습니다. 그것은 나에게 여전히 미스터리입니다.

이전에 제안한 두 가지를 생각하고 시도했지만 실패했습니다.

1. _selectAll() 에서 호출된 _getFilteredOrders() 함수에 newProps가 필요하기 때문에 componentWillReceiveProps가 작동하지 않습니다.
2. selectedIds 를 상태에 저장하지 않고 파생시키는 방법을 생각할 수 없었습니다.

방금 내 사용 사례에서 완전한 예 를 만들었습니다. 최대한 이해하기 쉽게 만들어 봤습니다.

당신이 볼 수 있다면 올바른 방향으로 저를 가리켜 주시기 바랍니다. 이것을 제대로 이해할 수 있다면 다른 사람들에게도 도움이 되도록 블로그 게시물에서 이 예를 공유하겠습니다.

@chanakasan , 어서, 이것은 프로덕션 코드처럼 보입니다. 나는 그것을 전부 읽고 당신의 프로젝트를 무료로 도와주지 않을 것입니다.

그러나 올바른 방향을 알려줄 수 있습니다.

1. componentWillReceiveProps() 및 componentDidUpdate() 이전 및 다음 소품에 액세스할 수 있습니다. 이는 공식 React 문서에서 분명히 알 수 있습니다.
2. 코드의 전체 복사 붙여넣기에서 이제 사용자가 토글할 수 있는 선택된 ID를 저장하기 위해 상태를 사용한다는 것이 분명해졌습니다. 상태를 사용하는 것은 괜찮지만 여전히 componentWillReceiveProps() 는 다시 렌더링을 두 배 적게 트리거합니다. (어쨌든 componentWillReceiveProps() 이후에 렌더가 발생하기 때문에 setState() 는 다음 렌더의 상태를 업데이트합니다.)
3. 문서를 살펴보십시오. 시간을 절약하고 다른 사람을 존중하십시오.

@me-andre 문서에서 다음 줄을 사용하여 componentWillReceiveProps 에 대한 귀하의 요점을 이해한다고 생각합니다.

this.setState()를 호출하면 componentWillReceiveProps()가 호출되지 않습니다.

그러나 componentWillReceiveProps 를 사용할 때 주의할 점은 nextProps를 함수에 전달해야 한다는 것입니다.

나는 당신의 조언을 따르려고 노력할 것입니다. 감사합니다.

Btw, 내 프로덕션 프로젝트를 무료로 도와주려는 의도는 아니었습니다. :). 내 사용 사례에 대한 공백을 채우는 이전의 짧은 예보다 더 완전한 예입니다.

이것을 shouldComponentUpdate와 함께 사용하면 어떻게 될까요?
구성 요소 상태를 업데이트하거나 다시 렌더링하지 않으려는 경우
하지만 props를 받은 후 수동 스크립트 작업을 수행하기 위해 최신 props를 사용하려면 this.props가 필요합니다.

내 해결 방법은 원하는 기능을 실행하기 전에 this.props를 새 소품으로 설정하는 것입니다.

ComponentDidMount 또는 이를 위한 후크가 있으면 정말 좋을 것입니다. 왜요? 때로는 React 수명 주기에 의존하지 않는 다른 계산을 수행해야 하기 때문입니다.

예: 크기를 조정할 수 있는 상위 구성 요소가 있습니다. 하위 구성요소는 지도 크기를 조정하는 기능이 있는 OpenLayer 지도를 렌더링하는 역할을 합니다. 그러나 자식이 부모로부터 소품을 받고 React 수명 주기 내에서 다른 계산도 커밋한 후에 발생해야 합니다.