Suggestion: rename "ref" prop in Controller render()

Hello,

Is your feature request related to a problem? Please describe. During my migration from V5 to V6, I used the following syntax to simplify moving from the as prop to the render Controller prop, since most of the time, there was a 1-1 match between the names of the passed props and the component props (value, onChange…)

<Controller name={"myName"} render={p => <MyComponent {...p}/>}/>

Note that the following syntax is described in the doc, so I thought it would be an easy and convenient way to make the migration easier.

However, I found out that 6.10 recently added a ref prop, and while I think it’s a good idea to be able to pass down a ref, it causes the following error to show up on the console for most of my controlled functional components : Function components cannot be given refs. Attempts to access this ref will fail. Did you mean to use React.forwardRef()?

I certainly don’t want to wrap all of my functional form components with forwardRef (sometimes tricky to do in TypeScript, and not always relevant) and of course, I can choose to not include the ref prop in what I pass down to the render() component, but I wonder if maybe it would be a good idea to rename this ref prop?

I think it makes some sense because :

• ref are unlike other props so passing down a ref prop has some gotchas (can trigger errors in console, doesn’t work out of the box with functional components…)
• Most components used with RHF should be functional, since class components are kinda legacy now. So it would mean we would have to be extra careful when passing down the render() props, and even more also when using the as prop (I’ve checked that with the as prop, it also passes down the ref prop, and unlike render(), there doesn’t seem to be a way out of this problem, although as is no longer the recommended way)

Describe the solution you’d like Considering that ref is a special prop “reserved” by React, I suggest renaming the ref passed down by Controller to something else, like controllerRef. Then it would be up to the developer to bind this ref to either the component ref or other prop (inputRef, etc…)

[dadouam]

Thank you for your answer, I totally understand why you’d hesitate to introduce a breaking change here and your other reasons. So I’ll close this issue for now.

Btw, thanks for your review on my PR and keep up your good work on your awesome lib 😄

[dadouam]

Indeed, changing the name requires a code change, although I’m not sure if it would break a lot of projects since it’s a recent addition. I think the problem with the current ref prop is that it can only work for some specific cases unlike the other props (e.g an <input/>, or some third-party components that provide a focus() method such as React-Select, though it’s pretty nice when it does work that way!) so personally I think a renaming to inputRef (or perhaps focusRef to make it more visible that RHF expects this ref to have a focus() method?) would make sense to avoid confusion over what this ref is supposed to do and prevent some warnings. I’d totally understand if you keep it that way though 😄

Btw, another suggestion about this line:

const onFocusRef = React.useRef(onFocus || (() => ref.current.focus()));

I suggest adding a console.warn if typeof current.focus !== 'function' to make it apparent that this ref only works on elements/components that provide a focus method (for reference, at first, I tried to pass this ref to a react-dates datepicker, and during validation, it threw a ref.current.focus is not a function error)