Нормальный / стандартный способ сравнения prevProps в componentDidUpdate

Question

Это произошло потому, что во время создания прототипа я обнаружил, что входящие новые свойства могут быть массивом сложных объектов, поэтому prevProps.myProp===this.props.myProp всегда равно false. JSON.stringify их обоих перед сравнением работает, но кажется ненадежным.

Я пытаюсь написать многоразовую функцию для компонентов класса, которая сравнивает предыдущие / новые реквизиты в componentDidUpdate реакции. Например:

componentDidUpdate(prevProps) {
    // First, get difference here, possibly using a lib like npm 'deep-object-diff'.
    // ...or just JSON.stringify both and do string comparison
    const changes = getTheDifference(prevProps, this.props)

    // Don't do anything if there's no changes.
    if (!changes) return

    // Then I want to do something like:
    this.setState( Object.assign(this.state, changes) )
}

... это будет означать, что каждый раз, когда входящие реквизиты меняются, они немедленно отражаются в состоянии. У меня возникли проблемы с поиском подходящей библиотеки diff, но я все еще чувствую, что мне не нужно этого делать, и я чего-то упускаю - есть ли общепринятый "нормальный" способ сделать это, или у меня есть эта проблема просто признак:

• Компонент пытается сделать слишком много / состояние слишком сложное?
• Я должен отображать реквизиты для состояния с чем-то вроде Redux? (пытаясь избежать этого до тех пор, пока это не станет абсолютно необходимым)
• Я слишком много думаю, иногда лог c в компоненте componentDidUpdate просто сложен и уникален?

Answer 1

это будет означать, что каждый раз, когда входящие реквизиты меняются, они немедленно отражаются в состоянии

Да, это неправильно. Когда я только начинал, я делал то же самое.

1. state - это нечто, «принадлежащее» этому компоненту (примечательно: не все компоненты вообще нуждаются в состоянии!).
2. props - это то, что «принадлежит» более высокому компоненту.

Лучший пример:

ComponentA передал идентификатор ComponentB в качестве опоры. ComponentB использует этот идентификатор для выполнения запроса API (например).

Статус / результаты этого запроса API формируют часть состояния ComponentB (он «принадлежит» вашему компоненту). Идентификатор, переданный как опора, НЕ является частью состояния ComponentB (он принадлежит ComponentA или может быть где-то выше в дереве, которое передало его как опору в ComponentA).

Когда свойство id изменяется, ComponentB будет необходимо сделать еще один запрос API.

EDIT:

Сложность методов жизненного цикла является причиной того, что React настоятельно рекомендует функциональные компоненты.

Вы должны думать о компонентах как о функциях. Намного проще написать logi c, если вы думаете об этом как о вводе -> выводе.

componentDidUpdate был перемещен в useEffect со списком зависимостей, так что вы можете сказать - запустите это функция, но только когда эта опора изменяется - это хороший способ разбить массивные componentDidUpdate методы на крошечные читабельные / проверяемые фрагменты.

Я слышал, что многие люди говорят, что хуки разрушили реакцию, но я категорически не согласен с ними. React увидел проблемы, с которыми люди сталкивались в сообществе из-за неправильного использования компонентов на основе классов / экземпляров, и вместо того, чтобы читать лекции о том, как их правильно использовать, они подтолкнули людей к написанию более качественных компонентов, внедрив более простые API-функции, хотя они все еще могут и будут злоупотреблять - с ними обычно проще иметь дело, чем с классами, и они хорошо согласуются с композицией над наследованием и декларативным над императивом.