Creatable.js mutates props.options, effectively changing it in parent Component as well

The component Creatable.js has the function createNewOption () which contains the following line

options.unshift(option);

When this executes, it will directly mutate the options property, something that not only seems like an anti-pattern for React, but can result in a changed value in the Parent component as well.

Given the following example, when onChange is being called after a new option has been created, the options property of the Parent component has already been changed.

class CreatableWrapper extends React.Component {
    static propTypes = {
        options:        React.PropTypes.array.isRequired
    }
    constructor(props){
        this.onChange = this.onChange.bind(this);
    }

    onChange(newValue) {
        const { options } = this.props;

        // When a new option has been created in Creatable, 
        // the options property here has been changed.
        console.log({ options });
    }

    render() {
        const { options } = this.props;

        return <Creatable {...{ options, onChange: this.onChange }} />
    }
}

Is this something that is a temporary but known behaviour that will change in the future? Is it a behaviour that is here to stay, or is it simple a bug?

[bpartridge]

If we want the Creatable to “keep track of” the fact that things that were added are valid options, it should either:

• Make the user/parent responsible for ensuring that options includes all things that have ever been passed to onChange, if that is the desired behavior. Simply removing the offending unshift call and updating examples/Creatable.js to append to this.state.options would do the trick.

• Or, own its own state, and pass down something to the underlying Select like options: [...options, this.state.createdOptions] rather than unshifting. However, this should be optional; for instance, if you’re reusing a form multiple times in a row without unmounting it, you may not want your custom value from last time to be autosuggested this time (i.e. if that data could be custom to each record).

I’d highly recommend the first approach; the second seems too “magical” for such a reusable component.

[jtbandes]

The secret to happiness: never upgrade any software