A Better Way To Handle Vue Props?

Подписаться 21 тыс.

Просмотров 4,2 тыс.

50% 1

🤖 WebDevDaily: www.webdevdaily.io
📕 Nuxt 3 Course: www.learnnuxt.dev/
📕 Vue 3 Crash Course: johnkomarnicki.gumroad.com/l/...
🚀 Join the channel : / @johnkomarnicki
🤖 Website: johnkomarnicki.com/
🐦 Twitter: / john_komarnicki
#vue #vue3 #nuxt #nuxt3

Наука

Опубликовано:

21 фев 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 37

@brendonvz 4 месяца назад

Great simple video!

@julisch94 3 месяца назад

I personally don't like to use the ["field"] accessor because it feels error-prone. What if I spell field wrong?

@karlstenator 4 месяца назад

Great video, thanks for sharing.

@JohnKomarnicki 4 месяца назад

Thanks for watching!

@cindysi63 4 месяца назад

Nice tip. Thanks

@aqordeon 13 дней назад

this video develop my Vue skill. thanks.

@russianstan 4 месяца назад

What about inheriting attributes in child component with this approach?

@joshuaberrios 4 месяца назад

Gained a subscriber out of me. This was great. Never thought of doing this. Going to try to implement this next week at my job.

@JohnKomarnicki 4 месяца назад

Awesome! Be sure to let me know how that goes!

@hinogi 3 месяца назад

So, what about if you have two objects? I guess you can't use multiple v-binds but how would you handle that scenario?

@alimaher1 4 месяца назад

Nice video, but I'm not sure if this idea scales well with bigger objects with many props and some nested objects.

@JohnKomarnicki 4 месяца назад

Hey, thanks for the comment. First, i don't see an issue with nested objects. It would work the same, it would just be an object within the component. Secondly, if your component has many props, even though it would require a bit more code to define all these props, to me it would still be a good idea. This way you know what exactly is being used within the component. Looking at a big single object as a prop to me is very granular. But it's all preference at the end of the day. There really is no wrong way

@pavelino17 4 месяца назад

Nice video, does this also work with passing additional props that are not in the User object? say any additional text. Can i then go v-bind="User" :text="myText" and just add the text prop to the defiineProps?

@JohnKomarnicki 4 месяца назад

Yeah, I believe that should work. You’d just have to ensure you don’t pass a prop name already being declared in that object otherwise you might encounter some issues.

@pavelino17 4 месяца назад

@@JohnKomarnicki cool thanks, I'll try it out

@Stefano-eo 4 месяца назад

If you destruscture the props, are you not losing the ref?

@JohnKomarnicki 4 месяца назад

No, you would not!

@yoanestradablanco1608 4 месяца назад

Good video

@JohnKomarnicki 4 месяца назад

Thank you! 🙌

@nguyennguyen6924 4 месяца назад

this is more likely a personal taste , there is no bad side passing an object via props so we dont have to define so many props inside child component , this takes less time . but I agree with you at readability point .

@JohnKomarnicki 4 месяца назад

Yeah, as I mentioned, the other ways I showed we’re not wrong. Just a preference at the end of the day

@Saeid-Za 4 месяца назад

Why not use the whole User as a root prop for the child? Somthing like "defineProps()" and if I want to only use some fields of User (not the whole User) using built-in Pick or Omit would be helpful. In this scenario calling and passing the Component and the Component code would be as minimal as possible

@JohnKomarnicki 4 месяца назад

I think this would work? However, as i mentioned the other ways i showed were not wrong. This approach i showed is just another way of handling it. At the end of the day it's all up to preference and what you prefer!

@RomanDawydkin 4 месяца назад

An interesting but controversial approach. What if we need to add another property later?

@JohnKomarnicki 4 месяца назад

You would just add it as a prop in the component. Would be very simple to do

@cant_sleeeep 3 месяца назад

dude, just go with the defineprops macro

@MightyArts 4 месяца назад

Why don't you just define the User type within the UserCard component itself, instead of defining it somewhere else, and then importing it here? Collocate the types, it will achieve the same readability that you're looking for here.

@JohnKomarnicki 4 месяца назад

Typically you'd have this object defined in the parent component, so it would need to be typed there. So creating an external type does make sense in this case. Yes, the types in the file would show what exactly the object is, but to me it's just not very clear. This approach i showed is just another way of handling it. At the end of the day it's all up to preference and what you prefer!