Renamed createRef .value attribute to .current

[bvaughn]

Based on team discussion about awkwardness of inputRef.value.value.

Docs have been updated as well, via 12d7c16.

[trueadm]

Did we want to also ensure that the ref object is valid by checking if it has the current property inside it? This relates to something @sophiebits mentioned the other day.

[trueadm]

We should check for current, otherwise awesome!

[bvaughn]

Sounds like you're advocating some new functionality? Inside of commitAttachRef?

[gaearon]

Yes, we should warn here if the object doesn't have an own current property. Because it means they probably passed something else accidentally.

[gaearon]

(This probably doesn't block the alpha but we need to add it to final release checklist. It should be a three line change though.)

[bvaughn]

Sure, sure. I just wanted to clarify what was being suggested 👍

[bvaughn]

Okay. Added a DEV warning for this, plus a test.

[alexkrolick]

Docs note:
I made the new callback ref example use an object instead of the usual direct reference so that it would have the same access API as createRef.

ref={el => this.someRef.current = el}
ref={this.someRef = el}

Idk if that is too much indirection. It could def cause some "could not access property 'current' of undefined" issues if not initialized.

reactjs/react.dev@12d7c16#diff-5ff76597e6c547982df2b2e42f2f83c0R279

[bvaughn]

I don't see much value in showing an object wrapper for the callback ref example:

this.textInput = { current: null }; // initial placeholder for the ref

My vote for the callback example would just be to write to this.textInput directly.