No good reasons to remove string refs from react-native

[jacmkno]

There are multiple problems with it:

• It requires that React keeps track of currently rendering component (since it can't guess this). This makes React a bit slower.
• It doesn't work as most people would expect with the "render callback" pattern (e.g. <DataGrid renderRow={this.renderRow} />) because the ref would get placed on DataGrid for the above reason.
• It is not composable, i.e. if a library puts a ref on the passed child, the user can't put another ref on it (e.g. Any better way to get refs in ReactTransitionGroup? #8734). Callback refs are perfectly composable.

Originally posted by @gaearon in #8333 (comment)

[jacmkno]

The reasons that supposedly gave origin to the idea of removing string refs from react native are just not good enough.

It requires that React keeps track of currently rendering component (since it can't guess this). This makes React a bit slower.

They can be implemented at compiler level as a syntactic sugar, or just properly keeping track of things. What exactly makes it so hard to implement this properly? The win here is READABILITY.

It doesn't work as most people would expect with the "render callback" pattern (e.g. ) because the ref would get placed on DataGrid for the above reason.

It would be an obvious mistake if the programmer creates multiple components with the same string ref.

It is not composable, i.e. if a library puts a ref on the passed child, the user can't put another ref on it (e.g. #8734). Callback refs are perfectly composable.

There are many simple ways to solve this issue without losing string refs, possibly accessing the parent component or through contexts.

Just give a try to fix the implementation. Having some issues is no good reason for killing a good a good feature.