Redux: connect ()로 다시 렌더링되지 않는 구성 요소

리듀서의 작업 처리 결과를 통해 저장소에서 데이터가 설정 / 업데이트 / 삭제됩니다. 감속기는 앱 슬라이스의 현재 상태를 수신하고 새로운 상태를 다시 가져올 것으로 예상합니다. 구성 요소가 다시 렌더링되지 않는 가장 일반적인 이유 중 하나는 필요한 변경 사항이 적용된 상태의 새 복사본을 반환하는 대신 감속기에서 기존 상태를 수정하기 때문입니다 ( 문제 해결 섹션 확인 ). 기존 상태를 직접 변경하면 Redux는 상태 차이를 감지하지 않으며 저장소가 변경되었음을 구성 요소에 알리지 않습니다.

따라서 감속기를 확인하고 기존 상태를 변경하지 않는지 확인합니다. 도움이 되었기를 바랍니다.

@ernieturner는 말 외에 있는지 확인 mapStateToProps 당신의 함수 connect(mapStateToProps)(YourConnectedComponent) 기능은 국가 관련 매핑 (이 경우 entities ) 연결된 구성 요소가 듣기는 그래서 상태의 그 조각에.

또한 connect() 는 얕은 비교를 수행합니다. https://github.com/rackt/react-redux/blob/d5bf492ee35ad1be8ffd5fa6be689cd74df3b41e/src/components/createConnect.js#L91

연결된 상태의 모양이 변경되지 않았기 때문에 업데이트를 수행하지 않는 것으로 가정 할 수 있습니다.

아, 알았어! 내 mapStateToProps 에서 상태에서 개체를 추출하려고했지만 올바른 키를 지정하지 않았습니다. entities.users[login] 를 추출하는 대신 entities.users[id] . entities.users 개체는 login 문자열로 키가 지정되었으므로 숫자 id 를 찾을 수 없을 때 실제로 변경된 소품이 없으므로 다시 렌더링 할 필요가 없습니다.

도와 주셔서 감사합니다! 시간을내어 도와 주셔서 정말 감사합니다.

뿡뿡
말도 안 돼. connect() 강제 변경 사항을 확인하는 방법은 무엇입니까? 그렇지 않으면 모든 더 깊은 수준의 상태에 대해 수십 개의 컨테이너 구성 요소를 만들어야합니다. 정상이 아닙니다

합리적인 크기의 앱에는 반드시 많은 연결된 구성 요소가 있어야합니다. 하나의 최상위 연결 구성 요소가있는 경우 상태가 전혀 변경 될 때마다 불필요하게 앱의 많은 부분을 다시 렌더링하게됩니다. 그리고 당신은 react-redux의 주요 최적화 중 하나를 제거 할 것입니다. 이것은 구독 상태가 변경 될 때만 다시 렌더링하는 것입니다.

복잡한 상태 쿼리를 평가해야하는 경우 reselect를 사용하여 속도를 높이십시오.

트윗 담아 가기

깊은 비교 문제를 해결하기 위해 트리의 낮은 위치에서 연결하는 것이 반드시 필요한 것은 아니라는 점을 명확히하는 것이 도움이 될 수 있습니다.

구성 요소 트리의 낮은 위치에 연결하면 실제로 _performance_에 도움이 될 수 있지만 심층 비교 문제에 대한 근본적인 해결책은 아닙니다. 깊은 비교 문제에 대한 해결책은 리듀서가 상태를 불변으로 업데이트하는 것이므로 얕은 비교는 더 깊은 상태가 언제 변경되었는지 알기에 적합합니다.

즉, 리듀서가 기존 상태 객체를 변경하지 않고 새 상태를 반환하는 한, 최상위 구성 요소를 큰 중첩 상태 부분에 연결하는 것은 _ 얕은 비교에서도 잘 작동합니다.

@naw 그 팁을 주셔서 감사합니다. 이를 바탕 으로이 문제가 발생한 곳에 새로운 감속기를 추가했습니다.

const reducers = combineReducers({
    //...bunch of reducers which always return objects of 3 or 4 properties that change sometimes but
    // the shape stays the same
    dataVersion: (state = Symbol(), action = {}) => {
        switch (action.type) {
            case SAME_ACTION_AS_THE_ONE_THAT_UPDATES_A_COMPLEX_PROPERTY:
            case ANOTHER_ACTION_THAT_ALSO_UPDATES_A_COMPLEX_PROPERTY:
                return Symbol():
            default:
                return state;
        }
    }
})

그래도 여전히 이상하게 느껴집니다. 감속기가있는 경우 :

    switch (action.type) {
       case UPDATE_THIS:
           return {a: action.a, b: action.b, c: action.c};
       default:
           return state;
     }

이전 상태와 동일한 모양 인 새로 초기화 된 객체를 반환한다는 사실은 previousState !== newState 를 트리거하기에 충분해야합니다. 매번 변경 불가능한 데이터를 반환해야한다면 정체성보다는 모양을 얕게 비교하는 것이 더 비효율적 인 것 같습니다. (그것이 Redux가 실제로하는 일이라고 가정하면, 그것은 내 Symbol 해결 방법이 작동한다는 사실로 인해 그것이 진행되고 있다고 생각하게 만듭니다.)

이 특별한 경우에는 더 많은 컨테이너 구성 요소를 추가해도 문제가 해결되지 않습니다. 슬프게도 설명을 위해 전체 github 프로젝트에 연결할 수는 없습니다. 이것이 제가 여기서 다루고있는 회사의 비공개 소스 항목이기 때문입니다.

@Zacqary 현재 상태와 이전 상태의 비교는 완전 동일 (===)으로 수행됩니다. stateProps (mapStateToProps의 결과) 비교는 얕은 동등으로 수행됩니다.

쫑끼리

mapStateToProps 는 상점에 도달하여 연결된 구성 요소의 데이터를 "조립"합니다.

mapStateToProps 는 상점에서 다양한 조각을 가져와 새로운 stateProps 개체의 키에 할당합니다.

결과 stateProps 객체는 매번 새 것이므로 (아이덴티티가 변경됨) stateProps 객체 자체의 객체 아이덴티티를 비교할 수 없습니다 .--- 우리는 아래로 내려 가야합니다. 레벨을 확인하고 @jimbolla가 말한 것처럼 shallowEqual 가 작동하는 각 값의 개체 ID를 확인합니다.

일반적으로 상태 조각의 객체 ID가 _ 변경되지 않고 _ 일부 중첩 된 속성이 변경되는 방식으로 리듀서를 작성할 때 문제가 발생합니다. 이것은 변경되지 않은 상태로 새로운 상태를 반환하는 것이 아니라 상태를 변경하는 것입니다. 이로 인해 react-redux 은 (는) 실제로 무언가가 _did_ 변경되었을 때 아무것도 변경되지 않았다고 생각하게합니다.

이전 상태와 동일한 모양 인 새로 초기화 된 객체를 반환한다는 사실은 previousState! == newState를 트리거하기에 충분해야합니다.

일부 상태 조각에 대해 새 개체를 반환하고 mapStateToProps 해당 상태 조각을 키 중 하나의 값으로 사용하면 react-redux 에서 개체 ID가 변경된 것을보고 다시 렌더링을 방지하지 않습니다.

예상대로 작동하지 않는 특정 사항이 있습니까? Symbol 해결 방법이 무엇을 의미하는지 잘 모르겠습니다.

추가 구성 요소를 단순히 connected() 구성 요소로 이동하여 소품을 상속해야하는지 여부를 고려할 가치가 있습니다. connect() 두 가지 구성 요소를 시도하여이 문제를 해결했지만 불필요한 복잡성이었습니다.

@ernieturner 나는 이것이 오래 문제 해결 섹션 링크를 업데이트하고 싶을 수도 있습니다.

건배

나는이 문제가 있었지만 정확히는 아닙니다.
다음과 같이 상태에 속성을 적용했습니다.

  constructor(props){
    this.state = {
      text: props.text
    }
  }

그리고 그것은 작동하지 않았습니다. 그래서 소품에서 직접 값을 적용했습니다.

{this.props.text}

그리고 그것은 잘 작동합니다 :)

@AlexanderKozhevin 내가 착각하지 않는 한, 생성자에 super(props) .
일반적으로 super(props) 를 호출하기 전에는 this 을 (를) 사용할 수 없습니다.

@ cdubois-mh 맞아요, 감사합니다.

맞춤형 앱 루트 감속기를 작성했으며 그 문제가 발생했습니다.
전체 상태의 복사본 반환
{...state}
루트 감속기가 끝날 때 도움이되었습니다.

@daedalius 그것이 감속기가 작동하는 방식입니다.
작업이 관련이없는 경우 상태를 반환하거나 예상 수정 된 값이있는 상태 복사본 을 반환해야합니다.

복사본을 반환하지 않으면 react가 항상 값이 변경되었음을 감지 할 수있는 것은 아닙니다.
(예 : 중첩 된 항목을 수정하는 경우)

이 상태를 확인하십시오.

{
    "clients": [
        { "name": "John", "cid": 4578 },
        { "name": "Alex", "cid": 5492 },
        { "name": "Bob",  "cid": 254 }
    ]
}

클라이언트의 이름을 수정했지만 상태의 복제본을 반환하지 않는 경우 상태를 수정하지 않고 배열의 개체를 수정 한 것입니다.

객체 자체는 여전히 이전과 동일한 참조를 가지므로 react가 변경 사항을 놓칠 것입니다.
복제본을 반환하면 상태 자체의 참조가 이제 달라지고 (새 객체이기 때문에) 반응이 전체 다시 렌더링 프로세스를 시작합니다.

내가 틀렸다면 저를 수정하십시오.하지만 이것이 감속기가 작동하는 것을 이해하는 방법입니다.

네, 맞습니다. 또한 @daedalius는 _ 항상 _ state 의 얕은 복사본을 만들고 싶지 않습니다. 변경된 경우에만 그렇게해야합니다. 그렇지 않으면 불필요한 구성 요소를 다시 렌더링 할 수 있습니다.

강제 업데이트

<AfterConnect
    _forceUpdate={Symbol()}
/>

@BrookShuihuaLee 그게 무슨 뜻이야? 코드에 대한 정보 나 설명을 제공하지 않았습니다. 그것은 무엇을합니까? 현재 진행중인 토론과 관련이있는 이유는 무엇입니까?

@CedSharp _forceUpdate = {Symbol ()}을 설정하면 shallowEqual 함수는 false를 리턴합니다.

@BrookShuihuaLee 첫 번째 답변에 이와 같은 설명을 포함하면 사람들이 더 잘 이해할 수 있다면 좋을 것입니다 ^^

트윗 담아 가기

@BrookShuihuaLee : 나쁜 생각 인 것 같습니다. 왜 그렇게하고 싶습니까?

@BrookShuihuaLee, 나는 @markerikson에 동의합니다.
상태가 변경되지 않았을 때 클론을 반환하지 않아야하는 이유가 있습니다. 솔루션이 필요한 것으로 보이는 유효한 예제를 제공 할 수 없다면 Redux가 작동하는 방식을 둘러 보지 않는 것이 좋습니다.

뿡뿡
뿡 빵뀨
AfterConnect 구성 요소는 설계 상 자주 다시 렌더링되기 때문입니다. 상위 구성 요소가 다시 렌더링 될 때 다시 한 번 다시 렌더링해도됩니다. 부모 구성 요소에서 모든 계산을 수행하고 AfterConnect에 대한 수많은 소품을 설정하고 싶지 않습니다.

@BrookShuihuaLee , 죄송 합니다만 귀하의 구성 요소가
내가 제대로 이해한다면, 당신은 자신의 커스텀 컴포넌트에 대해 이야기하고 있습니까? ForceUpdate는 React 세계에서 매우 권장하지 않는 것이므로 솔루션으로 권장하지 않습니다.

대신 상태가 아닌 다른 곳에서 변경 사항을 찾는 관찰 가능한 솔루션을 사용할 수 있습니까? 상태를 수정하지 않고 특정 구성 요소를 다시 렌더링해야하는 이유는 모르겠지만 다시 렌더링해야하는 이유를 알고 있다면 mobx와 같은 것을 사용할 수 있습니까?
(https://github.com/mobxjs/mobx)

귀하의 솔루션이 무엇인지, 왜이 상황에 적용되는지 이해하려고합니다.

@CedSharp 모든 사람이 forceUpdate를 사용해야한다는 의미는 아닙니다. 그러나 추천은 하나이고 선택은 다른 것입니다. React는 개발자를 위해 ReactComponent.prototype.forceUpdate를 유지합니다. 사람들은 선택이 필요합니다.

저는 다른 선택을하려고했습니다. 아마도 최선의 선택이 아닐 수도 있습니다.

최적은 아니지만 앱 상태를 잘못 구성했기 때문에이 문제가 발생했습니다. 나는 문제를 일으킨 상태의 슬라이스에서 얕은 필드를 업데이트하여 얕은 비교 문제를 해결했습니다.

case SOME_ACTION:
      return {
        ...state,
        ts: (new Date).getTime(),
      };

IMO는 좋은 솔루션은 아니지만 현재 바인딩 상태에있는 모든 사람에게 (즉, 하루가 끝날 때 릴리스해야 함) 빠른 수정이며 다른 곳에서 렌더링을 강제 할 필요가 없습니다.

깊게 중첩 된 상태에서도 얕은 비교가 작동하도록 코드를 리팩토링해야합니다.

상태는 변경 불가능해야합니다. 감속기에서 상태를 자세히 복사하면 연결에서 얕은 비교가 충분하고 효과적입니다.

내 문제는 그 안에 배열이있는 객체가 있습니다. 얕은 비교 였기 때문에 자식 배열 내의 개체에 도달하지 못했습니다. mapStateToProps 👍🏼에서 lists:state.obj 대신 list:state.obj.list 를 사용하여 문제를 해결했습니다.

방금이 문제가 발생했으며 첫 번째 답변을 읽은 후 감속기를 확인하고 거기에 오타가 있음을 알았습니다. 속성 이름을 변경하고 INITIAL_STATE를 업데이트했지만이 문제가있는 작업으로 업데이트중인 키를 변경하는 것을 잊었습니다.

기본적으로 구성 요소에서 사용되지 않은 임의의 키를 업데이트하고 있었으므로이 임의의 키가 업데이트 될 때 다시 렌더링되지 않을 것입니다.

감속기에서 오타를 확인하십시오! :)