RFC: register input value transformation

[bluebill1049]

Context

Input value transform is always a headache for every developer, while this is not going to be a complete solution to solve all the use cases, but it's a step ahead in the right direction. We will focus on register function to start with and stay close and aligned with web standard: https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement

Pros

• easy to implement and document for usage
• web standard

Cons

• make API a bit confusing, since register used to use for rules only.
• This is not going to be a silver bullet to solve all the problems with input data transformation.
• more API and increase bundle

Proposal

new config valueAsNumber, valueAsDate as part of the register options payload.

Option A

register({
  max: 5,
  valueAsNumber: true,
})

Option B

register(
  {
    max: 5,
  }, 
  {
    valueAsNumber: true, // transform related function only
  }
);

Potential extra option

This way the user is more flexible in terms of retrieving input values, eg: valueAsBoolean is not a standard, so we can't include that as an option, but the user can use setValueAs callback to transform the value.

register(
  {
    max: 5,
  }, 
  {
    setValueAs: (data) => parseInt(data); // a call back to transform value
  }
);

Important Notes

• valueAs* will not affect what the user is entering, it's nothing like a mask input, rather reading the value of the input.
• validation will run against the transformed value instead of what's in the view.

Implementation

The complexity of this feature should be at the medium level, we just have to confirm the API decision and write unit tests for the implementation itself.

• change register option type
• update reading input values with extra options
• invest impact with validation

PR: #3489

Poll result

[bluebill1049]

@stramel you may be interested in this one as well.

[paambaati]

@bluebill1049 Thanks for this RFC! I'm all in for the setValueAs option, as that would help build a lot of complex transforms.

Some questions —

1. What will the types look like for the transformed fields? I'm assuming the output of valueAs* will be used.
2. Can setValueAs be async?
3. On your point about the bundle size? Can this be made opt-in and tree-shakeable?

[bluebill1049]

What will the types look like for the transformed fields? I'm assuming the output of valueAs* will be used.

Yes :)

Can setValueAs be async?

No, keep it simple.

On your point about the bundle size? Can this be made opt-in and tree-shakeable?

unfortunately, it can't be tree shaken, as it will be baked into the core.

[SergeyWebDeveloper]

@bluebill1049 , please tell me, will this functionality be available in the Controller and I understand correctly that this is a replacement for this https://react-hook-form.com/advanced-usage#TransformandParse?

[bluebill1049]

This feature will be focused on register method, the transform usage with Controller in the above link is still valid. In fact, to achieve this in Controller is easier, onChange(doYourParase(e.target.value))

[SergeyWebDeveloper]

Thank you for the clarification)

[bednar85]

I like the setValueAs option too. Like @paambaati I feel that it offers the most flexibility without introducing a handful of one-off booleans. The only problem I see is that the argument structure of register becomes a bit confusing. It would just need clear documentation if it takes 2 objects as arguments.

[bluebill1049]

good call! @bednar85 that's what I initially thought as well.

register(_, { valueAsNumber: true }) // not great

I think we just going to keep the arg as 'Options' now, which can include more in the long run. Let me know your thoughts.

[bluebill1049]

This is going live with 6.12.0