Issue 1:
The ES6 support announcement says:

the idiomatic way to specify class state is to just use a simple instance property. Likewise getDefaultProps and propTypes are really just properties on the constructor.

This makes a lot of sense to me, but I noticed some small inconsistencies that may be worth rethinking.

When using the original .createClass syntax, the value returned by getDefaultProps seems to be used at other points in the component lifecycle -- not just in the constructor. For example, if I inspect what gets sent to componentWillReceiveProps(props), I can see that the default props are applied.

This doesn't seem to be the case when using the ES6 class syntax, which means I have to duplicate code. Here's an example of what I mean:

class Control extends React.Component {

constructor(props) {
props.value = props.value || '';
super(props);
}

// ...

componentWillReceiveProps(props) {
props.value = props.value || '';
// Do something with props...
}

}

As you can see, I'm duplicating the expression props.value = props.value || ''. If I had more than one default, I'd obviously have a lot more duplication.

When using the .createClass method, I could return {value: ''} from the getDefaultProps method, and this would work, and I'd only have to do it once.

Does it make sense to restore this method to avoid unnecessary duplication? Is there another, more React-like approach that I'm not aware of?

Issue 2:
With other higher-order/wrapper components from other libraries, I can replace a component with a wrapped version of itself like this:

let Component = () => <div>hello world</div>;

// connect from react-redux
Component = connect(selector)(Component);
// withRouter from react-router
Component = withRouter(Component);

export default Component;

I don't see a lot of people do it this way, so I guess it's not recommended best practice. I know mutating is the devil and functional is always the way to go, but I think this is a lot cleaner because, 1) you don't have to nest a bunch of functions which increases the indent of the code and decreases readability, 2) you don't have to create a bunch of separate duplicate component names with obtuse names like ComponentWithRouter or ConnectedComponentWithRouterWithForwardedRef, and 3) your first definition of the component is just the pure display component that receives all the props it needs (it doesn't care where they come from), and then you define everything that "connects" to it separately.

Anyway, with forwardRef, reassigning the component like this seems to crash React.

Fine:

const UnforwardedComponent = ({ forwardedRef, ...props}) => <div>sup</div>
const Component = forwardRef((props, ref) => <UnforwardedComponent {...props} forwardedRef={ref} />;
export default Component;

Also fine:

const Component = forwardRef((props, ref) => <div {...props} ref={ref}>sup</div>;
export default Component;

Crashes:

let Component = ({ forwardedRef, ...props }) => <div>sup</div>;
Component = forwardRef((props, ref) => <Component {...props} forwardedRef={ref} />
export default Component;

I assume there's a under-the-hood reason why this doesn't work. But if it's at all possible, it'd be great to allow forwardRef to work in this manner.

Please let me know if I'm missing something obvious.