常见的反模式

你不应该把 props 保存到 state 中。它被认为是一种反模式 。例如：

export default class MyComponent extends React.Component {
    constructor() {
        super();

        this.state = {
            url: ''
        }

        this.onChange = this.onChange.bind(this);
    }

    onChange(e) {
        this.setState({
            url: this.props.url + '/days=?' + e.target.value
        });
    }

    componentWillMount() {
        this.setState({url: this.props.url});
    }

    render() {
        return (
            <div>
                <input defaultValue={2} onChange={this.onChange} />

                URL: {this.state.url}
            </div>
        )
    }
}

prop url 保存在 state 上，然后进行修改。相反，选择将更改保存到状态，然后使用 state 和 props 构建完整路径：

export default class MyComponent extends React.Component {
    constructor() {
        super();

        this.state = {
            days: ''
        }

        this.onChange = this.onChange.bind(this);
    }

    onChange(e) {
        this.setState({
            days: e.target.value
        });
    }

    render() {
        return (
            <div>
                <input defaultValue={2} onChange={this.onChange} />

                URL: {this.props.url + '/days?=' + this.state.days}
            </div>
        )
    }
}

这是因为在 React 应用程序中，我们希望拥有单一的事实来源 - 即所有数据都由一个组件负责，而且只有一个组件。此组件负责将数据存储在其状态中，并通过 props 将数据分发到其他组件。

在第一个示例中，MyComponent 类及其父级都在其状态中维护 url。如果我们在 MyComponent 中更新 state.url，则这些更改不会反映在父级中。我们失去了单一的事实来源，通过我们的应用程序跟踪数据流变得越来越困难。将此与第二个示例进行对比 - url 仅维护在父组件的状态中，并在 MyComponent 中用作 prop，因此我们保持单一的事实来源。