Snackbar's get stuck open when receiving new props, regardless of nature

[dlindahl]

The changes in lines 93-113 of #1668 broke my usage of Snackbars. If the component receives new props while it is open, the Snackbar is closed, regardless of the nature of the new incoming props. And then, when the "_oneAtTheTimeTimerId" executes, the Snackbar opens, again regardless of what the current state is actually is.

I have a component that reflects the state of an async operation that results in two Snackbars showing. Updating to 0.13.1 caused the first "Requesting..." Snackbar to reappear, and stay visible, even tho the prop changes do not relate at all to the Snackbars themselves.

Changing line 106 to open: _this.props.openOnMount seemed to work around the issue, but that whole block of code seems really odd to me, so I'm not sure that is the best solution.

I tried to make a jsbin/jsfiddle/codepen example, but this project doesn't doesn't exist on a CDN nor does it have a distributable, so that ruled out anything quick. My click handler pseudo-code is as follows:

  handleRequest() {
    this.refs.snackbarRequesting.show();
    this.setState({
      requestLabel: 'Creating...',
      disabled: true
    });
    setTimeout(() => {
      this.setState({
        requestLabel: 'Requested',
        disabled: true
      });
      this.refs.snackbarRequested.show();
      this.refs.snackbarRequesting.dismiss();
    }, this.props.requestDelay);
  }
  render() {
    return (
      <Card>
        <Button
          disabled={this.state.disabled}
          onClick={this.handleRequest}
          primary
          ref="create"
          >
            {this.state.requestLabel}
        </Button>
        <Snackbar message="Requesting..." ref="snackbarRequesting"/>
        <Snackbar
          autoHideDuration={1250}
          message="Requested"
          ref="snackbarRequested"
        />
      </Card>
    );
}

That second call to setState causes the snackbarRequesting state to revert back to open because of the lines of code highlighted above, and since the operation has completed, the Snackbar will remain open.

[oliviertassinari]

@dlindahl Thanks for opening this issue.

Regarding the logic of those line of code. The goal is to achieve the material spec stating that only one snackbar should be displayed at the same time.
In order to do it, the first step is to have only one instance of this component.
Then, we also have to solve the following problem: update the message displayed while the snackbar is already displaying a message.
This is what this logic is for. I have added an animation.

Regarding your example, I was expecting the Pure context mixin to prevent this, but was wrong since
componentWillReceiveProps is called before shouldComponentUpdate.

So, I think that you can use one Snackbar component to achieve the same with less logic on your application side. However, the logic you describe should first assert that we have new stuff to render.
What do you think?

[oliviertassinari]

@dlindahl Can you see if #2024 fix your issue?