[v4, ts, yup, script setup, composition api] different type passed to useForm and on handleSubmit

Hello, I searched through open/closed issues but didn’t find the answer. What I’m trying to accomplish is to have initial values type (e.g. accepting null as initial value) different from submitted values.

Example:

import { string, InferType } from 'yup';
interface FormValues {
    name: string | null;
}

const validationSchema = object({
    name: string().required().nullable()
})

export type SubmittedFormValues = InferType<typeof validationSchema>
type test = SubmittedFormValues['name'] // string

So the initial value can be string or null but after successful submission I’m 100% sure it’s string. Initial value comes from an api and it’s possible to get null as an initial value.

Then in my .vue file I’m using it like that:

const dataFromApi = ref<DataFromAPI>();
const { handleSubmit, resetForm } = useForm<FormValues>({
    validationSchema,
  });
  
const onSubmit = handleSubmit((formValues) => {
    type test = typeof formValues['name'] // string | null, but I want it to become just string
})
  
onMounted(() => {
    dataFromApi.value = await getDataFromApi();
    resetForm({
        values: {
            name: dataFromApi.value?.name // string | null
        }
    })
})

I know that I can just use type assertion in handleSubmit but I’m curious if there’s another way without using ‘as’?

[mzastue]

Yeap, but this is something that you have to do manually. But InferType from yup do it for you. The point is there is no way to anyhow integrate it with submit function from vee-validate. I mean if you have validation added into form, form won’t be submitted if validation fails, so why initial form values are still applied into submit data?

[logaretm]

so why initial form values are still applied into submit data?

For stuff like required, optional sure it can be easy to narrow it down but there are a couple of blockers here.

1. I don’t think dynamic typing can work well without you asserting it via casting or a type predicate in a lot of cases. The simplest reason I can think of is how would it interact with custom validation rules. If you add a custom validation function that validates phone numbers that don’t allow false values, how would vee-validate narrow it down? I don’t think this is a major blocker and vee-validate/yup can just ignore the custom validation inference.

2. The major blocker with using yup types internally, is it forces all typescript users to install it with vee-validate as a dependency, otherwise, they will get typescript errors while building/type checking. I dropped using the yup types internally because of this since I got a lot of complaints about it.

Still, I personally see the value and would like to take a stab at it sometime soon, happy to have suggestions.