On antipatterns:

> setState() in componentWillMount()

componentWillMount() is an anti-pattern. It is not a true lifecycle hook. It is invoked on the server, unlike componentDidMount and friends. Anything you do here can, and perhaps should, be done in the constructor.

> Mutating State without setState()

  handleClick() {
    // BAD: We mutate state here
    this.state.items.push('lorem');

    this.setState({
      items: this.state.items
    });
  }

There's no explanation as to why this is bad, just that it's bad and you shouldn't do it. Because.

The real reason, in this particular example, is that any lifecycle hooks that rely on comparing two consecutive versions of the state will not work, because the older version of the state will have been mutated.

> Using indexes as keys... Bad... This limits the optimizations that React can do.

> Good... React would be able to reorder elements without needing to reevaluate them as much.

This isn't any incentive at all. I don't do premature optimizations and so I'd happily use key={index} if optimization was the only issue and performance didn't suck.

The real incentive to use a value that uniquely identifies the entity being rendered as the key, rather than an index, is to prevent the representation of entities from being removed and added back to the DOM, so I can animate their addition and removal, via CSS transitions, when they are actually added and removed. Using the index as the key would make the wrong elements animate. Also, I wouldn't want certain elements to unnecessarily go through the end of their lifecycle only to be created again, especially if their lifecycle hooks are tied to various side effects (e.g. API endpoints being called).