RFC: new custom hook useController
#3487
Replies: 3 comments 11 replies
-
Maybe we expose as |
Beta Was this translation helpful? Give feedback.
-
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 ;) |
Beta Was this translation helpful? Give feedback.
-
This is live with 6.13.0 |
Beta Was this translation helpful? Give feedback.
-
Context
At the moment, our
useController
is really theregister
function fromuseForm
, 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 withController
, and discover we can easily expose that logic into a new custom hookuseController
, and potentially give the user another option to work with inputs that don't exposeref
.Here is the link for the PR where I moved
Controller
's logic into the hook: #3483Pros
Cons
with
Controller
with
useController
Proposal
This custom hook will still isolate the re-render within each hook, and here is the proposal usage:
Option A
Option B
This hook will share the same API as
Controller
as well. (exceptas
andrender
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:
Beta Was this translation helpful? Give feedback.
All reactions