ReactJS состояние против проп

Обновление 2016: Реакция изменилась, и объяснение "реквизит против государства" стало очень простым. Если компоненту необходимо изменить данные - поставьте его в состояние, иначе в реквизитах. Поскольку реквизиты доступны только для чтения.

Какая точная разница между реквизитами и состоянием?

Вы можете найти хорошее объяснение здесь (полная версия)

Из React doc

реквизиты неизменяемы: они передаются от родителя и "принадлежат" родителям. Чтобы реализовать взаимодействия, мы вводим переменное состояние в компонент. this.state является частным компонентом и может быть изменен путем вызова this.setState(). Когда состояние обновляется, компонент повторно отображает себя.

От TrySpace: при обновлении реквизита (или состояния) (через setProps/setState или parent) компонент повторно отображает.

Чтение из Мышление в действии

Пропустите каждый из них и выясните, какой из них является состоянием. Просто задайте три вопроса о каждой части данных:

• Проходит ли он от родителя через реквизит? Если это так, возможно, это не государство.

• С течением времени меняется? Если нет, возможно, это не состояние.

• Вы можете вычислить его на основе любого другого состояния или реквизита в своем     компонент? Если это так, оно не указано.

Я не уверен, отвечаю ли вы на ваш вопрос, но я обнаружил, что, особенно в большом/растущем приложении, шаблон Container/Component работает невероятно хорошо.

По существу у вас есть две компоненты React:

• "чистый" компонент отображения, который касается стилизации и взаимодействия с DOM;
• компонент контейнера, который занимается доступом/сохранением внешних данных, управлением состоянием и отображением компонента отображения.

Пример

N.B. Этот пример, вероятно, слишком прост, чтобы проиллюстрировать преимущества этого шаблона, так как он достаточно подробен для такого простого случая.

/**
 * Container Component
 *
 *  - Manages component state
 *  - Does plumbing of data fetching/saving
 */

var PostEditorContainer = React.createClass({
  getInitialState: function() {
    return {
      text: ""
    };
  },

  componentWillMount: function() {
    this.setState({
      text: getPostText()
    });
  },

  updateText: function(text) {
    this.setState({
      text: text
    });
  },

  savePost: function() {
    savePostText(this.state.text);
  },

  render: function() {
    return (
      <PostEditor
        text={this.state.text}
        onChange={this.updateText.bind(this)}
        onSave={this.savePost.bind(this)}
      />
    );
  }
});


/**
 * Pure Display Component
 *
 *  - Calculates styling based on passed properties
 *  - Often just a render method
 *  - Uses methods passed in from container to announce changes
 */

var PostEditor = React.createClass({
  render: function() {
    return (
      <div>
        <input type="text" value={this.props.text} onChange={this.props.onChange} />
        <button type="button" onClick={this.props.onSave} />
      </div>
    );
  }
});

Преимущества

Сохраняя логику отображения и управление данными/состоянием раздельно, у вас есть повторно используемый компонент отображения, который:

• можно легко повторить с помощью разных наборов реквизитов, используя что-то вроде react-component-playground
• можно обернуть другим контейнером для другого поведения (или объединить с другими компонентами для создания более крупных частей вашего приложения

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

Этот шаблон также делает запись и реализацию модульных тестов намного более простой.

Несколько раз повторив большое приложение React, я обнаружил, что этот шаблон делает вещи относительно безболезненными, особенно когда у вас есть более крупные компоненты с вычисленными стилями или сложные взаимодействия с DOM.

* Прочитайте образец потока и посмотрите на Marty.js, который в значительной степени вдохновил этот ответ (и Я использовал много в последнее время) Redux (и react-redux), которые очень хорошо реализуют этот шаблон.

Я думаю, вы используете анти-шаблон, который Facebook уже объяснил на этой

Здесь вы найдете:

React.createClass({
  getInitialState: function() {
    return { value: { foo: 'bar' } };
  },

  onClick: function() {
    var value = this.state.value;
    value.foo += 'bar'; // ANTI-PATTERN!
    this.setState({ value: value });
  },

  render: function() {
    return (
      <div>
        <InnerComponent value={this.state.value} />
        <a onClick={this.onClick}>Click me</a>
      </div>
    );
  }
});

При первом отображении внутреннего компонента он будет иметь {foo: 'bar'} в качестве значения prop. Если пользователь нажимает на привязку, состояние родительского компонента будет обновляться до {value: {foo: 'barbar}}, инициируя процесс повторного рендеринга внутреннего компонента, который получит {foo:' barbar} новое значение для prop.

Проблема заключается в том, что, поскольку родительский и внутренний компоненты имеют ссылку на один и тот же объект, когда объект получает мутацию в строке 2 функции onClick, поддержка внутреннего компонента будет изменяться. Итак, когда процесс повторного рендеринга запущен и будет вызываться componentUpdate, this.props.value.foo будет равен nextProps.value.foo, потому что на самом деле this.props.value ссылается на тот же объект, что и nextProps.value.

Следовательно, поскольку мы пропустим изменения на опоре и короткое замыкание процесса повторного рендеринга, пользовательский интерфейс не будет обновляться с "бара" до "Barbar"