;
+}
+```
+
+`createRef` requires a explicit type annotation to ensure type correctness.
+
+After `componentDidMount` lifecycle `divRef.value` will be filled with element/component reference:
+
+```js
+componentDidMount() {
+ this.divRef.value instanceof HTMLDivElement === true
+}
+
+render() {
+ return (
+
+ {this.props.children}
+
+ );
+}
+```
+
+# Drawbacks
+
+Callback refs are easier to use when child with ref and parent have different lifetime. Consider this example:
+
+```js
+class CallbackRefExample extends React.Component {
+ // Callback refs offer a centralized place
+ // to perform side effects.
+ divRef = (div) => {
+ if (div) {
+ this.div = div;
+ this.div.addEventListener('foo', onFoo);
+ } else {
+ this.div.removeEventListener('foo', onFoo);
+ this.div = null;
+ }
+ }
+
+ onFoo = () => {
+ console.log('hello');
+ }
+
+ render() {
+ if (this.props.enabled) {
+ return ;
+ } else {
+ return null;
+ }
+ }
+}
+```
+
+We could write an equivalent example with object refs by using `componentDidMount` and `componentDidUpdate`. However, by the time `componentDidUpdate` fires, we have no way to access the previous ref value to remove the listener. So we'd have to "mirror" the ref value in a separate instance variable. This becomes very tedious and error-prone.
+
+The conclusion here is that for advanced use cases (such as side effects during ref attachment and detachment), callback refs are preferable. Still, in most cases this is not necessary, and object refs are sufficient.
+
+# Alternatives
+
+One potential alternative is to do nothing, and keep string refs and callback refs. The problem with keeping string refs is that they prevent some future work on React, including advanced compilation strategies. So we need a migration path off of them.
+
+Another potential alternative is to fully embrace callback refs but deprecate string refs. However, there is a lot of feedback suggesting that people struggle with understanding and using the callback ref API, and a simper option is necessary.
+
+The `createRef` API could potentially be implemented as a userland package. However, it would be a one-liner, and most people would not know about it. If we wanted everybody to use it, we might as well build it into React.
+
+# Adoption strategy
+
+Initially, we will release the object refs alongside the existing string and callback refs as a minor update. This update will also include a `` component which enables deprecation messages for its subtree. This lets people catch string refs usage in their components and replace with the new API (or callback refs, if they prefer) incrementally.
+
+String refs will be removed in an upcoming major release, so there will be enough time for migration.
+
+# How we teach this
+
+Callback and object refs solve different problems and crossing over in what they offer too - much like how components in React do currently.
+
+In most cases people would choose an object ref. They could use it when they only care about accessing the object reference. The ref object can be passed around, or stored in an array.
+
+Callback refs will be positioned as an advanced API. It is useful when someone likes to have fine-grained control over the node when it gets attached and detached, or to compose multiple refs.
+
+# Unresolved questions
+
+None.