ComponentWillReceiveProps против getDerivedStateFromProps

getDerivedStateFromProps не является прямой альтернативой componentWillReceiveProps исключительно из-за того, что он вызывается после каждого обновления, будь то изменение состояния, изменение свойств или повторный рендеринг родительского объекта.

Однако в любом случае простое возвращение состояния из getDerivedStateFromProps - неправильный путь, вам необходимо сравнить состояние и свойства перед возвратом значения. В противном случае с каждым обновлением состояние сбрасывается до props, и цикл продолжается.

Согласно документы

getDerivedStateFromProps is invoked right before calling the render method, both on the initial mount and on subsequent updates. It should return an object to update the state, or null to update nothing.

This method exists for rare use cases where the state depends on changes in props over time. For example, it might be handy for implementing a <Transition> component that compares its previous and next children to decide which of them to animate in and out.

Deriving state leads to verbose code and makes your components difficult to think about. Make sure you’re familiar with simpler alternatives:

If you need to perform a side effect (for example, data fetching or an animation) in response to a change in props, use componentDidUpdate lifecycle instead.

If you want to re-compute some data only when a prop changes, use a memoization helper instead.

If you want to “reset” some state when a prop changes, consider either making a component fully controlled or fully uncontrolled with a key instead.

P.S. Обратите внимание, что аргументы для getDerivedStateFromProps - это props и state, а не nextProps и prevProps.

Чтобы получить более подробную информацию,

Чтобы вносить изменения на основе изменения реквизита, нам нужно сохранить prevPropsState в состоянии, чтобы обнаруживать изменения. Типичная реализация будет выглядеть так:

static getDerivedStateFromProps(props, state) {
    // Note we need to store prevPropsState to detect changes.
    if (
      props.myPropsState !== state.prevPropsState
    ) {
      return {
        prevPropsState: state.myState,
        myState: props.myPropsState
      };
    }
    return null;
  }

Из ответных документов:

Note that this method is fired on every render, regardless of the cause. This is in contrast to UNSAFE_componentWillReceiveProps, which only fires when the parent causes a re-render and not as a result of a local setState.

Вы эффективно переопределяете свое состояние с помощью текущих свойств каждый раз после вызова setState(). Поэтому, когда вы устанавливаете флажок, вызывается (e) => this.handleMethod(e, comp.myState), который предполагает вызовы setState() для обновления отмеченного состояния флажка. Но после этого будет вызван getDerivedStateFromProps() (перед рендерингом), который отменяет это изменение. Вот почему Безоговорочное обновление состояния из реквизита считается анти-паттерном.

Наконец, я решил свою проблему. Отладка была мучительной:

// Child Component

// instead of this
// this.props.onMyDisptach([...myPropsState])

// dispatching true value since myPropsState contains only numbers
this.props.onMyDispatch([...myPropsState, true])

Это потому, что у меня есть два условия: 1) при изменении флажка (компонент) 2) при нажатии кнопки сброса (дочерний компонент)

Мне нужно было сбросить состояния при нажатии кнопки сброса. Итак, при отправке состояния реквизитам для кнопки сброса я использовал логическое значение, чтобы знать, что это изменение от сброса. Вы можете использовать все, что захотите, но вам нужно это отслеживать.

Теперь, здесь, в компоненте, я нашел некоторые подсказки о различиях между componentWillReceiveProps и getDerivedStateFromProps после отладки вывода консоли.

// Component
static getDerivedStateFromProps(props, state) {
    const { myPropsState: myState } = props
    // if reset button is pressed
    const true_myState = myState.some(id=>id===true)
    // need to remove true value in the store
    const filtered_myState = myState.filter(id=>id!==true)
    if (true_myState) {
      // we need to dispatch the changes to apply on its child component
      // before we return the correct state
      props.onMyDispatch([...filtered_myState])
      return {
        myState: filtered_myState
      }
    }
    // obviously, we need to return null if no condition matches
    return null
  }

Вот что я нашел результаты вывода консоли:

• getDerivedStateFromProps регистрирует сразу же при изменении свойств

• componentWillReceiveProps регистрирует только после того, как дочерний элемент распространяет изменения реквизита

• getDerivedStateFromProps не отвечает на изменения реквизита (я имел в виду изменения отправки, как в примере кода)

• componentWillReceiveProps реагирует на изменения реквизита

• Таким образом, нам нужно было внести изменения в дочерний компонент при использовании getDerivedStateFromProps.

Процесс вставки истинного значения в состояние, которое мне нужно, потому что getDerivedStateFromProps обрабатывает все изменения, в отличие от componentWillReceiveProps, обрабатывает только дочерний компонент, отправляющий изменения в реквизиты.

Кстати, вы можете использовать настраиваемое свойство, чтобы проверить, изменилось ли оно, и обновить значение, если getDerivedStateFromProps, но по какой-то причине мне нужно настроить эту технику.

В моих формулировках может быть некоторая путаница, но я надеюсь, что вы ее поймете.