常見的反模式

你不應該把 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，因此我們保持單一的事實來源。