its nice to have a youtuber here that uses vue3 with the most latest syntax ( script setup) and keeps teaching about new concept and ideas! Will definetly keep checking this channel out because its a scarce vue resource
Thanks for the tip, one note that should be considered is that the defineProps validation is in development only and has no runtime cost in production mode. The solution provided here does have runtime cost in production mode. Another, less related note is that Zod does not support adding custom multi-language validation errors in a developer friendly way, thats why I always go back to a simpler way of validating forms in general. But all and all, a lovely library. Thanks for the video ❤️
well, if we wrap the validations in a reusable class as erik suggested, it makes this even better, cus we can control that. For example, my apps always make use of a debug flag ("?debug" in the url) that allows me to debug stuff in production if I need, with this approach I could validate the inputs if debug==true, and jsut retun; in case its not.
Great video! Thank you, Erik. In C# we have a Package called Fluentvalidation. It has similar functions for validations. Usually you create a class UserValidation where you abstract the validation logic. Inside you pass rules like RuleFor(x=> x.Name).NotNull().WithMessage("Name should not be null"). Then in the save user process you create an instance of this class and pass your user object. The result instance has a property if it has issues and the error messages. So you can pass it to the frontend. I think with Zod it should be possible to do a similar approach with compositions.
Thanks again for sharing your knowledge, Erik. I'm REALLY happy to see you're using ZOD. You mentioned "we can use ZOD for form validation as well" It would be great to see how you're doing form validation with ZOD... More in particular... Which is the preferred way to combine "error" messages with I18N ? In other words... Depending on the chosen language in the app, the user has to see the message "firstname is a required field" or "voornaam is een verplicht veld"... I hope you got my point... Thanks in advance for coming back on this...
I've been using with composition api I basically have a const props with WithDefaults and defineProps for each component, there use my interfaces to type the props, just a few of them I use defaultvalues, I've been using Yup as a validator tool, very similar to zod as I can see, cheers! love your videos
Zod is good for server-side use, because we usually don't care about the size of the server-side application bundle. But for client-side validation, Valibot looks better. It has almost the same API as Zod, but it saves bundle size.
Hi Erik, it’s quite interesting, Zod really make the thing much more easier. I just think the original way to type the props are really good because it came with less complexity. Otherwise using the Typescript is really a good way to do that. Using schemas worth in big scenarios. The original way is quite good and completed.
I would really love the prop validation on the compile side (vue, vite combination).. vueTsc is not working with options API and also not with more complex types (Classes).. from the console.warn perspective is (which is here mentioned) good only on runtime.. if you have 1 component used in multiple places (or inside the library) this is not enough.. also using vscode plugin is only checking opened files which is also not good enough.. I think react/vite/typescript is more mature for now.. sadly.. Vue 2 with webpack had this options...
I definitely like defining props via the type argument. Never liked withDefaults because then you end up defining many of the same properties twice. Same is even more true with destructuring, which is annoying, but at least you get the benefit of the toRefs as well with it
Is destructuring still reactive? Because it doesn't look like it is. If it "is magically" reactive, I am unsure if that is good or bad. If the code reads as one thing but is actually something else.....
@@Nerlon93 normally the `const prop = defineProps()` object is reactive, and you read the properties of the prop object. But I have never played with the experimental vite config before, and don't feel like setting up a whole environment to test.. If `const { test = 'hello' } = defineProps()` isn't reactive at all, and is now a 1 hit pony, then this is a massive no no of a pattern.. but, as I said, I haven't played with the experimental config, so if it actually does return a ref, then all is well. but then it makes no sense with the `= 'hello' ` part.. It would basically be magic by obscurity, which is terrible.. It's bad enough that `defineProp` and `defineEmits` internals are already kinda `magic` to begin with.
@@Nerlon93 I think you are misunderstanding the meaning of reactive vs immutable. `isReactive(props)` props is a `readonly` `reactive` object. When the props are altered from the outside, it triggers the reactive system into updating. I've just had a very quick look at that is going on with destructureProps, it seems it makes it work like a fake ref. I say fake, because it cannot be passed into composables that expect a ref. And it only keeps it reactivity within the context of the setup function.. This seems counterintuitive since it's just more wishy washy hidden magic going on. I will be recommending our codebase stick to `toRefs()`
Good question, maybe I should have made this more clear. It does keep reactivity , it's a new feature with 3.3 -> blog.vuejs.org/posts/vue-3-3#reactive-props-destructure
Does class change work similar if the class you apply to the component is defined in Tailwind CSS AFTER the initial class you defined inside the component? I guess you DO NEED to use twMerge in this case.
It's a bummer zod infering doesn't work with Props. It would also be little bit conficlting when setting a default value using Zod using the .default() function, the infered type would have tha value as not nullable. But the Prop would be optional :D
As @wvovaw3052 says Valibot is better for front end stuff due to the smaller bundle size. I've been able to build a type from a valibot schema i've created then use it as a prop type. For example ```vue import * as z from 'valibot' //Define the clItemSchema const clItemSchema = z.object({ id: z.number(), heading: z.string(), mainContent: z.string(), email: z.string([z.email()]) }) //Use the clItemSchema to define the type of the clItem type CLItem = z.Input const { clItem } = defineProps() //Try to parse the clItem using the clItemSchema try { z.parse(clItemSchema, clItem) } catch (error) { console.log("Prop clItem is invalid:", error) } ``` It has a similar api to Zod so if you import it as 'z' copilot thinks that's what your using and fills stuff in for you
How do you use props?
sxzz/vue-simple-props
Эрик, это очень сомнительное видео(
its nice to have a youtuber here that uses vue3 with the most latest syntax ( script setup) and keeps teaching about new concept and ideas! Will definetly keep checking this channel out because its a scarce vue resource
Thanks for the tip, one note that should be considered is that the defineProps validation is in development only and has no runtime cost in production mode.
The solution provided here does have runtime cost in production mode.
Another, less related note is that Zod does not support adding custom multi-language validation errors in a developer friendly way, thats why I always go back to a simpler way of validating forms in general.
But all and all, a lovely library.
Thanks for the video ❤️
Thanks for the feedback!
well, if we wrap the validations in a reusable class as erik suggested, it makes this even better, cus we can control that. For example, my apps always make use of a debug flag ("?debug" in the url) that allows me to debug stuff in production if I need, with this approach I could validate the inputs if debug==true, and jsut retun; in case its not.
Great video! Thank you, Erik.
In C# we have a Package called Fluentvalidation. It has similar functions for validations.
Usually you create a class UserValidation where you abstract the validation logic.
Inside you pass rules like RuleFor(x=> x.Name).NotNull().WithMessage("Name should not be null").
Then in the save user process you create an instance of this class and pass your user object.
The result instance has a property if it has issues and the error messages. So you can pass it to the frontend.
I think with Zod it should be possible to do a similar approach with compositions.
Nice!
Thanks again for sharing your knowledge, Erik.
I'm REALLY happy to see you're using ZOD.
You mentioned "we can use ZOD for form validation as well"
It would be great to see how you're doing form validation with ZOD...
More in particular... Which is the preferred way to combine "error" messages with I18N ?
In other words... Depending on the chosen language in the app, the user has to see the message "firstname is a required field" or "voornaam is een verplicht veld"...
I hope you got my point...
Thanks in advance for coming back on this...
Will do! And good to see you commenting again !
I've been using with composition api I basically have a const props with WithDefaults and defineProps for each component, there use my interfaces to type the props, just a few of them I use defaultvalues, I've been using Yup as a validator tool, very similar to zod as I can see, cheers! love your videos
Zod is good for server-side use, because we usually don't care about the size of the server-side application bundle.
But for client-side validation, Valibot looks better. It has almost the same API as Zod, but it saves bundle size.
And I'm not sure I'd want to apply this runtime validation to every component, but it's a nice addition for some cases tho
Zod IS Magic, in vue, in graphql backend, everywhere
Hi Erik, it’s quite interesting, Zod really make the thing much more easier. I just think the original way to type the props are really good because it came with less complexity. Otherwise using the Typescript is really a good way to do that.
Using schemas worth in big scenarios. The original way is quite good and completed.
i just prefer the vue props type definition, it's just clean
That makes sense.
Nice work, tks. I use yup for validations,
Using zod (or just vue-types) is pretty cool tho
I like it!
Hate the way programming is going sometimes.
specially with tailwind stuff😢
Next tutorial on Vuejs+Firebase 🔥
I would really love the prop validation on the compile side (vue, vite combination).. vueTsc is not working with options API and also not with more complex types (Classes).. from the console.warn perspective is (which is here mentioned) good only on runtime.. if you have 1 component used in multiple places (or inside the library) this is not enough.. also using vscode plugin is only checking opened files which is also not good enough.. I think react/vite/typescript is more mature for now.. sadly.. Vue 2 with webpack had this options...
I definitely like defining props via the type argument. Never liked withDefaults because then you end up defining many of the same properties twice. Same is even more true with destructuring, which is annoying, but at least you get the benefit of the toRefs as well with it
Great video, this one was so packed with good info and tips. Thanks!
Glad you enjoyed it!
Is destructuring still reactive? Because it doesn't look like it is.
If it "is magically" reactive, I am unsure if that is good or bad.
If the code reads as one thing but is actually something else.....
props aren't reactive. you'd have to go with toRef or maybe defineModel
@@Nerlon93 normally the `const prop = defineProps()` object is reactive, and you read the properties of the prop object.
But I have never played with the experimental vite config before, and don't feel like setting up a whole environment to test..
If `const { test = 'hello' } = defineProps()` isn't reactive at all, and is now a 1 hit pony, then this is a massive no no of a pattern..
but, as I said, I haven't played with the experimental config, so if it actually does return a ref, then all is well. but then it makes no sense with the `= 'hello' ` part.. It would basically be magic by obscurity, which is terrible..
It's bad enough that `defineProp` and `defineEmits` internals are already kinda `magic` to begin with.
@@ColinRichardson how is it reactive?
you have props = defineProps(text)
you cant have on this component a text prop is read only. it's not reactive
@@Nerlon93 I think you are misunderstanding the meaning of reactive vs immutable. `isReactive(props)` props is a `readonly` `reactive` object. When the props are altered from the outside, it triggers the reactive system into updating.
I've just had a very quick look at that is going on with destructureProps, it seems it makes it work like a fake ref. I say fake, because it cannot be passed into composables that expect a ref. And it only keeps it reactivity within the context of the setup function.. This seems counterintuitive since it's just more wishy washy hidden magic going on.
I will be recommending our codebase stick to `toRefs()`
Good question, maybe I should have made this more clear. It does keep reactivity , it's a new feature with 3.3 -> blog.vuejs.org/posts/vue-3-3#reactive-props-destructure
Does class change work similar if the class you apply to the component is defined in Tailwind CSS AFTER the initial class you defined inside the component? I guess you DO NEED to use twMerge in this case.
It's a bummer zod infering doesn't work with Props. It would also be little bit conficlting when setting a default value using Zod using the .default() function, the infered type would have tha value as not nullable. But the Prop would be optional :D
Thanks. very good info. Will update my doggie app asap
Glad it was helpful!
👋Hello! What theme do you use in the vs code?
You cannot add zod on defineProps because zod is at runtime and defineprops before at "build time"
Vue Props validation работает только в dev режиме.
Zod очень тяжёлая библиотека для проверки props
Reminder that at first, and until recently, Vue 3 didn't support using imported types in props (e.g. extending from it)
Yup
const prop = thats it
We use vee validate at work for forms but this is cool
defineProps()
As @wvovaw3052 says Valibot is better for front end stuff due to the smaller bundle size.
I've been able to build a type from a valibot schema i've created then use it as a prop type. For example
```vue
import * as z from 'valibot'
//Define the clItemSchema
const clItemSchema = z.object({
id: z.number(),
heading: z.string(),
mainContent: z.string(),
email: z.string([z.email()])
})
//Use the clItemSchema to define the type of the clItem
type CLItem = z.Input
const { clItem } = defineProps()
//Try to parse the clItem using the clItemSchema
try {
z.parse(clItemSchema, clItem)
} catch (error) {
console.log("Prop clItem is invalid:", error)
}
```
It has a similar api to Zod so if you import it as 'z' copilot thinks that's what your using and fills stuff in for you
Давайте признаем, что у Vue осталось много проблем с DX и Typescript
👍👍👍👍👍👍👍👍👍👍👏👏👏👏👏👏👏👏🙋♂🙋♂🙋♂
sxzz/vue-simple-props