Wrong TS typing of input.value when using parseValue/formatValue that convert types

[mmoo]

Are you submitting a bug report or a feature request?

A bug report I think

What is the current behavior?

So if I make a simple field that stores values of type A and uses some input that accepts values of type B, I get a weird type mismatch.
For example, I have a field of type Date that uses a simple html select as input (please see a sandbox link below). I add parseValue that gets string from select and returns Date to store, and I add formatValue which does the opposite.
In this case I would expect the input.value of FieldRenderProps to be a string but typescript infers its type as Date (in fact it's a string). So I see a TS error.

What is the expected behavior?

I would expect the input.value of FieldRenderProps to be a string.

Sandbox Link

https://codesandbox.io/s/strongly-typed-form-values-with-react-final-form-forked-nfmmq?file=/src/index.tsx

What's your environment?

react-final-form: 6.3.5
final-form: 4.20.1
typescript: 4.3.2

Other information

Maybe I'm doing something wrong. Would appreciate if anyone could help me to figure the things out.

[callmeberzerker]

This is not a bug.

You are explicitly setting the value of your field in your FormState to be of type Date | null and your Select component takes a value of type string. What are you confused about?

[mmoo]

@callmeberzerker As far as I understand the type parameter of the Field component describes the type of the value being stored in the form state. And if I use parse/format mechanism this type can be different from the type of the value passed to the input.
So, all I want is to be able to convert types using parse/format without having type errors. Is it legal at all?

[callmeberzerker]

Yep I understand what you want, and while I agree it it would be super cool if it was possible -> I am not sure how react-final-form can do it with TypeScript. I don't think that construct can be expressed via TS basically. As a practical workaround you can define the <Field<Date | string | null>>.

Also some 2cents from my side in general regarding form handling - you should prefer to store string in your form values.

The reason being let's take a Field that has parse/format for Number (stores the input value as Number in form state, formats it as a string). The big question is what happens if the user enters a 'string' -> well then you have 'NaN' in your form state... And if you think now it's easy I am gonna prevent the user to add characters at all, now you get (IMO) weird User-Experience where the user can press a button and his input not being reflected in UI... That's why I always erred on allowing the user to enter anything in the Field but have validation to nudge him towards the right set of instructions.

I never use parse - but I do use format (which is handling a Field value of the same type)... and when I use format I don't use the ReactFinalForm format but this library https://github.com/realadvisor/rifm -> because it has black magic wizardry inside where masked input is formatted properly even when doing modifications in the middle (near the Number separators lets say).

[mmoo]

@callmeberzerker I think that UX considerations stand apart from the issue I described. Yes, your example makes sense but I've had a couple of real life form fields that could win from such type conversion without harming the UX. For example I use a custom DatePicker component that accepts and returns Dates but I need to submit date-only formatted strings to server. And I prefer submitting form state unchanged without running it through some pre-submit converter. This is the case where type conversion through parse/format could help.

@mrfratello wow thanks! Your PR really fixes the thing for me 😍
Too bad it is unlikely to be merged. The repo looks abandoned.

[erikras]

Published fix in v6.5.4.