Merge pull request #4306 from brigand/patch-5

Blog: move "refs to custom components..." fixes #4305

_posts/2015-07-03-react-v0.14-beta-1.md

@@ -46,6 +46,8 @@ For now, please use the same version of `react` and `react-dom` in your apps to
 
 The other big change we're making in this release is exposing refs to DOM components as the DOM node itself. That means: we looked at what you can do with a `ref` to a DOM component and realized that the only useful thing you can do with it is call `this.refs.giraffe.getDOMNode()` to get the underlying DOM node. In this release, `this.refs.giraffe` _is_ the actual DOM node.
 
+Refs to custom component classes work exactly as before.
+
 ```js
 var Zoo = React.createClass({
   render: function() {
@@ -66,7 +68,7 @@ var Zoo = React.createClass({
 });
 ```
 
-This change also applies to the return result of `ReactDOM.render` when passing a DOM node as the top component. References to custom component classes work exactly as before.
+This change also applies to the return result of `ReactDOM.render` when passing a DOM node as the top component. As with refs, this change does not affect custom components (eg. `<MyFancyMenu>` or `<MyContextProvider>`), which remain unaffected by this change.
 
 Along with this change, we're also replacing `component.getDOMNode()` with `ReactDOM.findDOMNode(component)`. The `findDOMNode` method drills down to find which DOM node was rendered by a component, but it returns its argument when passed a DOM node so it's safe to call on a DOM component too. We introduced this function quietly in the last release, but now we're deprecating `.getDOMNode()` completely: it should be easy to change all existing calls in your code to be `ReactDOM.findDOMNode`. We also have an [automated codemod script](https://www.npmjs.com/package/react-codemod) to help you with this transition. Note that the `findDOMNode` calls are unnecessary when you already have a DOM component ref (as in the example above), so you can (and should) skip them in most cases going forward.