RFC: new custom hook useController

[bluebill1049]

Context

At the moment, our useController is really the register function from useForm, however, we all know this is problematic come to components which don't forward their input ref. Controller was been born as a solution to solve that problem and still provide us with good performance and isolating that rerender within each component. As I doing a quick refactoring with Controller, and discover we can easily expose that logic into a new custom hook useController , and potentially give the user another option to work with inputs that don't expose ref.

Here is the link for the PR where I moved Controller's logic into the hook: #3483

Pros

• custom hook with declarative API make it easier to manage with your individual component with hook form.
• potentially more extensible with new features in the long run.

Cons

• increase in package bundle size.
• you should consider using one hook per component, instead of Controller where you can throw multiple components together.

with Controller

return <>
  <Controller /> // ✅
  <Controller /> // ✅
</>

with useController

const { onChange, onBlur } = useController(); 
// const { onChange: onChange1, onBlur: onBlur1 } = useField();  not good idea to use multiple hook

return {
  <input onChange={onChange} onBlur={onBlur} ref={ref} />
}

Proposal

This custom hook will still isolate the re-render within each hook, and here is the proposal usage:

Option A

const { field: { onChange, onBlur, ref }, state: { isTouched, inValid } } = useController({
  name: 'test',
  rules: {}
  control, // optional
})

return {
  <input onChange={onChange} onBlur={onBlur} ref={ref} />
}

Option B

const { onChange, onBlur, isTouched, isInValid } = useController({
  name: 'test',
  rules: {}
  control, // optional
})

This hook will share the same API as Controller as well. (except as and render props)

Implementation

This one should be relatively easy, we just have to confirm the API decision and write unit tests for the custom hook itself.

PR: #3488

Poll result:

[stramel]

Maybe we expose as useControlledField?

[stramel]

I think keeping with the spirit of the library, the useField would remain a wrapper on register. Then add a new one, useControlledField, that is more descriptive of it being a controlled input. This will also ensure that this is a non-breaking change.

[bluebill1049]

You are right on that. Happy to adjust @stramel. updating.

[bluebill1049]

what about useController? I think it aligned with everything we have and it's used inside Controller now.

[kotarella1110]

I think users using https://github.com/react-hook-form/strictly-typed will be confused.
useController and useTypedController have completely different return values.

[bluebill1049]

validate points @kotarella1110 hopefully eventually we can deprecated useTypeController with TS 4.1 update (string literal). Most likely breaking change for v7 tho.

[barrymay]

Hiya - I'll chime in since I've actively used Controller in projects - I think Controller is perfect as is tbh! I'm generally never against a new hook convenience, but in this case, having the Controller component wrapping the actual control keeps the context of what you're doing well, especially if you are using it multiple times in a form.

That said, I'm not wholly against it if ppl find it useful, just think it's a bit of overkill ;)

[bluebill1049]

Hey Barry, How are you? Yes, a valid point above. That's one of my concerns as well. I prefer simplicity and less choice for users to make. One of the benefits I think it's cleaner when someone is building a design system, where a custom hook is for per component and make it more declarative and cleaner.

[barrymay]

Hey Bill - thanks I'm well! :) I agree for design systems and single use components, the hook can be very handy. Again, I'm not against it being there, but I just don't see myself using it :D

Keep up the great work! I love seeing all the continued progress!

[bluebill1049]

Thanks, @barrymay for your feedback as usual. 👍

[bluebill1049]

By the way, we won the OS award: #3183 there are credits that go to you as well. (I know you prefer to remain hidden.)

[barrymay]

I'm very honored and glad to have played my part - All credit to you and the team for keeping this going and growing!!

[bluebill1049]

This is live with 6.13.0