React. Обязательно ли использовать constructor(){...} чтобы задать state на основе props?

Question

[bormor]

Обнаружил, что можно задать state напрямую, на основе props

export default class Task extends Component{
    state ={
        currentText: this.props.text, // вот так
    }
    ...

т.е. задать state на основе пропс, не вызывая constructor.

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

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

Comments

[Алексей Уколов]

В современном Реакте для этого вообще следует использовать getDerivedStateFromProps.

[Антон Спирин]

Алексей Уколов, getDerivedStateFromProps используют в другом случае, это статическая альтернатива componentWillReceiveProps. Тут при каждом обновлении props будет вызов. Часто надо задать state на основе полученных свойств только один раз, при инициализации.

[bormor]

Антон Спирин, подскажите ваше мнение - в каких ситациях будет корректным применять этот код?

state ={
        currentText: this.props.text,
    }

[Антон Спирин]

bormor, ну, мы в проекте constructor вообще не используем. state на основе props задается тоже редко. Обычно дочернему компоненту передается часть state родительского компонента как props и колбек на обновление.

[bormor]

Антон Спирин, спасибо. Мне тоже такой подход кажется оптимальным.

[Алексей Уколов]

Антон Спирин, вы по ссылке-то сходите, там в первом же предложении написано, что вы не правы.

[Антон Спирин]

Алексей Уколов, видимо, вы его неправильно перевели и сделали неверные выводы. Вот прочитайте внимательно, выделил упущенную вами суть:

getDerivedStateFromProps is invoked after a component is instantiated as well as when it receives new props.

Cоветую так же ознакомиться с информацией по приведенной вами ссылке, изложенной после первого предложения. И вот это еще обязательно почитайте. По ссылке информация о предпосылках к изменению API методов жизненного цикла и руководство по миграции.
Простой пример, демонстрирующий принцип работы этого метода.

[Алексей Уколов]

Антон Спирин, ну да, сейчас и начальное состояние и изменения пропсов обрабатываются одним методом. Я ж с этим не спорю. Но вы говорите, что начальное состояние в нём не задаётся, а это не так.

getDerivedStateFromProps is invoked after a component is instantiated as well as when it receives new props.

Таким образом, если начальное состояние зависит от пропсов, его нужно задавать не в конструкторе и не в свойстве класса, а именно в getDerivedStateFromProps — в этом весь смысл данного метода. Изменения пропсов тоже будут в нём отрабатываться и меньше вероятность что-то забыть.

А чтобы избежать проблемы "при каждом обновлении props будет обновляться state" нужно просто в методе соответствующие проверки добавить, опять же в документации и rfc этот момент описан.

[Антон Спирин]

Алексей Уколов,

Но вы говорите, что начальное состояние в нём не задаётся, а это не так.

Где я такое написал? Вы придумывайте. Я написал, что "getDerivedStateFromProps это статическая альтернатива componentWillReceiveProps". Слово альтернатива тут не значит, что метод работает идентично. Вы что-то перепутали.
И для кейса автора нет никакого смысла использовать getDerivedStateFromProps. Больше кода, лишние вызовы и сравнения.

class Example extends React.Component {
  state = {
    number: this.props.number,
  };
}

против:

class Example extends React.Component {
  state = {};
  static getDerivedStateFromProps(nextProps, prevState) {
    if (prevState.number !== nextProps.number) {
      return { number: nextProps.number };
    }

    return null;
  }
}

Ваше утверждение, что "В современном Реакте для этого вообще следует использовать getDerivedStateFromProps." ничем не аргументированно. То, что его можно использовать в этом кейсе никто не спорит, но следует ли, вопрос очень спорный.
Главное, что вы не предоставили ни одного аргумента, почему так как делает автор, делать не следует.
При этом, вот что об этом говорится в официальной документации к текущей версии.

[Алексей Уколов]

Антон Спирин, а, ну да, у меня формулировка в этом плане неудачная. Я больше в качестве альтернативы скинул. Как правило, если начальное состояние зависит от пропсов, то нужно и за их изменениями следить тоже и тогда использовать getDerivedStateFromProps будет разумно. В коде из вопроса необходимости такой нет, но я предполагаю, что это всё-таки больше псевдокод, в котором выпилено многое из реального спора.

Answer 1

[Антон Спирин]

class properties экспериментальный синтаксис.
В этом случае поле state задается после (простой пример) вызова конструктора React.Component, в котором инициализируются преданные props. Поэтому когда вы определяете state, props уже определены и доступны.
Если используете transform-class-properties, он входит в stage-0, stage-1, stage-2, то смело используйте.

Comments

[bormor]

Спасибо за развернутый ответ.

Answer 2

[Moro Zota]

Это экспериментальный синтаксис
Это нормальная практика

Comments

[bormor]

Спасибо за ответ.

Насчет эспериментального синтаксиса state = {...} я был в курсе, удивило именно

state ={
        currentText: this.props.text, // вот это
    }

Смущает то, что в курсах даже за 2018 когда нужно задавать state на основе пропс, авторы переписывают state={...} на constructor(){...}

На это может быть какая-то причина? Или это у них сила привычки?

[Антон Спирин]

bormor, авторы курсов, видимо, так пишут потому, что не все используют transform-class-properties. Либо, в силу банального незнания механики этой экспериментальной фичи.