[V4] v-slot's "value" is of type unknown

[jagoncalves14]

What happened?

While opening the example in the Docs for using Vee-Validate along with Quasar, there is a TS error being thrown.

This happens because value from the v-slot is of type unknown and Quasar's q-input is expecting the value in the model-value to be of type string | number | null | undefined — which makes perfect sense.

So my question is:

• Is there any chance to attribute the right type to the value coming from the v-slot so it doesn't get its type as unknown?
• Does anyone know any trick to get around this?

Reproduction steps

1. Download the Stackblitz Demo from the Vee-Validate's docs.
2. Open the project in VSCode.
3. Make sure you're using Volar as your workspace TS tooling
4. Open App.vue
5. You can find the same TS errors from the description above.

Version

Vue.js 3.x and vee-validate 4.x

What browsers are you seeing the problem on?

• Firefox
• Chrome
• Safari
• Microsoft Edge

Relevant log output

No response

Demo link

https://stackblitz.com/edit/vee-validate-v4-quasar-framework?file=src%2FApp.vue

Code of Conduct

• I agree to follow this project's Code of Conduct

[jagoncalves14]

The best I've got so far is doing this:

But it would be really awesome if we could get to type this correctly.

If I try to add the types in that same line, I get the error saying the types are incompatible.

[logaretm]

Practically impossible till this RFC is approved/implemented. There are possible workarounds that can be implemented in vee-validate codebase like this but it would force devs to use a weird syntax to get this working.

Volar actually implemented the RFC under a feature flag in tsconfig. So it is possible to implement it once I figure out how to hack it for defineComponent API. But again this proposal is experimental and may not land in the final release.

Another workaround is to just mark the component value slot prop as any instead of unknown which is accurate somewhat. I might go with this to close this issue as no accurate typing mechanism seem to be ready publicly yet.

[jagoncalves14]

Got it @logaretm 👍 It sure is a TS limitation, that's a bummer.

Seems to me that for now I probably will go with the option of simply applying any for value like I did in here.

Thanks for the reply! Feel free to close if you think its best. If that RFC ever gets to be approved, we can probably make this issue back to life for instructing a solution.

[logaretm]

For now to mitigate this I will mark the field slot value as any which should be accurate enough for most use-cases with Field usage.