在 React 表单中更新道具更改状态

Question

我在 React 表单和正确管理状态方面遇到问题。 我有一个表单中的时间输入字段（在模态中）。 初始值在getInitialState设置为状态变量，并从父组件传入。 这本身工作正常。

当我想通过父组件更新默认的 start_time 值时，问题就出现了。 更新本身通过setState start_time: new_time在父组件中发生。 但是在我的表单中，默认的start_time值永远不会改变，因为它只在getInitialState定义了一次。

我尝试使用componentWillUpdate通过setState start_time: next_props.start_time强制更改状态，这确实有效，但它给了我Uncaught RangeError: Maximum call stack size exceeded错误。

所以我的问题是，在这种情况下更新状态的正确方法是什么？ 我是不是在以某种方式考虑这个错误？

当前代码：

@ModalBody = React.createClass
  getInitialState: ->
    start_time: @props.start_time.format("HH:mm")

  #works but takes long and causes:
  #"Uncaught RangeError: Maximum call stack size exceeded"
  componentWillUpdate: (next_props, next_state) ->
    @setState(start_time: next_props.start_time.format("HH:mm"))

  fieldChanged: (fieldName, event) ->
    stateUpdate = {}
    stateUpdate[fieldName] = event.target.value
    @setState(stateUpdate)

  render: ->
    React.DOM.div
      className: "modal-body"
      React.DOM.form null,
        React.createElement FormLabelInputField,
          type: "time"
          id: "start_time"
          label_name: "Start Time"
          value: @state.start_time
          onChange: @fieldChanged.bind(null, "start_time")

@FormLabelInputField = React.createClass
  render: ->
    React.DOM.div
      className: "form-group"
      React.DOM.label
        htmlFor: @props.id
        @props.label_name + ": "
      React.DOM.input
        className: "form-control"
        type: @props.type
        id: @props.id
        value: @props.value
        onChange: @props.onChange

Answer 1

componentWillReceiveProps 自 react 16 起被弃用：改用getDerivedStateFromProps

如果我理解正确，您有一个父组件将start_time传递给ModalBody组件，该组件将其分配给自己的状态？ 并且您想从父组件而不是子组件更新该时间。

React 有一些处理这种情况的技巧。 （请注意，这是一篇已从网络上删除的旧文章。这是当前组件 props 文档的链接）。

在getInitialState使用 props 生成状态通常会导致“真实数据来源”的重复，即真实数据在哪里。 这是因为getInitialState仅在首次创建组件时调用。

只要有可能，即时计算值以确保它们以后不会不同步并导致维护麻烦。

基本上，每当您将父级的props分配给子级的state ，渲染方法并不总是在道具更新时调用。 您必须使用componentWillReceiveProps方法手动调用它。

componentWillReceiveProps(nextProps) {
  // You don't have to do this check first, but it can help prevent an unneeded render
  if (nextProps.startTime !== this.state.startTime) {
    this.setState({ startTime: nextProps.startTime });
  }
}

Answer 2

显然事情正在发生变化...... getDerivedStateFromProps()现在是首选函数。

 class Component extends React.Component { static getDerivedStateFromProps(props, current_state) { if (current_state.value !== props.value) { return { value: props.value, computed_prop: heavy_computation(props.value) } } return null } }

（以上代码由 danburzo @ github 提供）

Answer 3

componentWillReceiveProps已被弃用，因为使用它“通常会导致错误和不一致”。

如果外部发生了变化，请考虑使用key完全重置子组件。

为子组件提供key属性可确保每当key的值从外部发生变化时，都会重新渲染该组件。 例如，

<EmailInput
  defaultEmail={this.props.user.email}
  key={this.props.user.id}
/>

关于它的表现：

虽然这听起来可能很慢，但性能差异通常是微不足道的。 如果组件具有在更新时运行的繁重逻辑，则使用键甚至可以更快，因为该子树绕过了差异。

Answer 4

还有componentDidUpdate可用。

函数签名：

componentDidUpdate(prevProps, prevState, snapshot)

以此为契机，在组件更新后对 DOM 进行操作。 不会在初始render调用。

请参阅您可能不需要派生状态文章，其中描述了componentDidUpdate和getDerivedStateFromProps反模式。 我发现它非常有用。

Answer 5

这样做的新钩子方法是使用 useEffect 而不是 componentWillReceiveProps 的旧方法：

componentWillReceiveProps(nextProps) {
  // You don't have to do this check first, but it can help prevent an unneeded render
  if (nextProps.startTime !== this.state.startTime) {
    this.setState({ startTime: nextProps.startTime });
  }
}

在功能钩子驱动组件中变为以下内容：

// store the startTime prop in local state
const [startTime, setStartTime] = useState(props.startTime)
// 
useEffect(() => {
  if (props.startTime !== startTime) {
    setStartTime(props.startTime);
  }
}, [props.startTime]);

我们使用 setState 设置状态，使用 useEffect 我们检查指定道具的更改，并在道具更改时采取行动更新状态。

Answer 6

你可能不需要派生状态

1.从父级设置一个键

当一个键发生变化时，React 会创建一个新的组件实例而不是更新当前的组件实例。 键通常用于动态列表，但在这里也很有用。

2. 使用getDerivedStateFromProps / componentWillReceiveProps

如果密钥由于某种原因不起作用（也许该组件的初始化成本非常高）

通过使用getDerivedStateFromProps您可以重置状态的任何部分，但此时（v16.7）似乎有点问题！，请参阅上面的链接以了解用法

Answer 7

来自反应文档： https : //reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html

当道具改变时擦除状态是一种反模式

从 React 16 开始，componentWillReceiveProps 已被弃用。 从反应文档，在这种情况下推荐的方法是使用

1. 完全受控的组件： ModalBody的ParentComponent将拥有start_time状态。 在这种情况下，这不是我喜欢的方法，因为我认为模态应该拥有这种状态。
2. 带有钥匙的完全不受控制的组件：这是我更喜欢的方法。 反应文档中的一个例子： https : //codesandbox.io/s/6v1znlxyxn 。 您将完全拥有ModalBody的start_time状态，并像您已经完成的那样使用getInitialState 。 要重置start_time状态，您只需更改ParentComponent的键

Answer 8

// store the startTime prop in local state
const [startTime, setStartTime] = useState(props.startTime)
// 
useEffect(() => {
  if (props.startTime !== startTime) {
    setStartTime(props.startTime);
  }
}, [props.startTime]);

这个方法可以迁移到类组件吗？

Answer 9

从他们的文档中可以清楚地看出：

If you used componentWillReceiveProps for re-computing some data only when a prop changes, use a memoization helper instead.

使用： https : //reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html#what-about-memoization

Answer 10

使用备忘录

op 的 state 推导是对 props 的直接操作，不需要真正的推导。 换句话说，如果您有一个可以直接使用或转换的道具，则无需将道具存储在 state 上。

鉴于start_time的状态值只是道具start_time.format("HH:mm") ，道具中包含的信息本身已经足以更新组件。

但是，如果您只想在 prop 更改时调用 format，按照最新文档执行此操作的正确方法是通过 Memoize： https ://reactjs.org/blog/2018/06/07/you-probably-dont- 需要派生状态.html#what-about-memoization

Answer 11

表单的数据源必须是基于用户输入的，在用户已经输入的情况下，任何导致子组件更新的情况，都会触发componentWillReceiveProps或者getDerivedStateFromProps操作，这时候比较后的值肯定不是相等，执行setState后，用户输入的值会发生变化，这不是一个错误吗？

Answer 12

我认为使用 ref 对我来说是安全的，不需要关心上面的一些方法。

class Company extends XComponent {
    constructor(props) {
        super(props);
        this.data = {};
    }
    fetchData(data) {
        this.resetState(data);
    }
    render() {
        return (
            <Input ref={c => this.data['name'] = c} type="text" className="form-control" />
        );
    }
}
class XComponent extends Component {
    resetState(obj) {
        for (var property in obj) {
            if (obj.hasOwnProperty(property) && typeof this.data[property] !== 'undefined') {
                if ( obj[property] !== this.data[property].state.value )
                    this.data[property].setState({value: obj[property]});
                else continue;
            }
            continue;
        }
    }
}