My answer:

• private states and global events
• mutable data without restriction
• render with side effects

I've trained myself very long time to think in functional programming's way so I maybe not the best one to answer this question but here're are some tips I got in building https://jianliao.com .

Back the time we are using Backbone we used Backbone.Events a lot to synchronise states among different views. It was quite troublesome as our app grow and the behaviors are hard to predict. After migrated to React the event emitters are still there, but we decide to make them as few as possible.

Facebook introduced immutable-js for JavaScript. React does not force people to use immutable data, but if someone use mutable objects everywhere he will find it very hard to optimise the performance after the app grows larger. Also immutable data is more reliable.

We already known it's bad idea to add side-effects in the function body of this.render. I found it also bad idea to have that in this.componentDidMount this.componentWillUnmount. If you are using tools like Redux which time travels you will find components mount and unmount for many reasons, and they are also part of the rendering process. So, don't introduce side-effects in lifetime hooks if you still have other choices.

• Calling setState in componentWillMount is an antipattern. In React components, you cannot set state before the component is mounted. So, instead of attempting to set the state in componentWillMount, you should do it in componentDidMount.

• Using isMounted is an antipattern.

• Props in getInitialState is antipattern. Using props to generate state in getInitialState often leads to duplication of "source of truth", i.e. where the real data is. This is because getInitialState is only invoked when the component is first created.Whenever possible, compute values on-the-fly to ensure that they don't get out of sync later on and cause maintenance trouble.

• Don't mutate dom explicitly via Jquery or anything you might get Two valid but unequal nodes with the same data-reactid error.

Thanks for the invite.

IMO, A good starting point to read is this nice pattern collection here and here

It's not super updated yet because it recommends Alt.js instead of Redux ;-)

Some more topics to throw in

• Inheritance (use composition instead!)
• getInitialState() (use props!)
• Flux (add any flux implementation only if you have a big messy component at the root of your component tree)
• State (try to force you and your co-workers to use functional stateless components, otherwise use higher order components as near as possible to the root of your component tree. Some other thoughts here)
• mixins (use ES7 decorators or functional wrappers instead)