The timing of this video is crazy. I was literally wrapping a prop in a ref and was wondering why my code was not behaving correctly. This video explanation was really helpful. Thank you for creating such an informative short video.
When the video came out, I watched and said to myself 'meh, it's a rare case'. Here coming back after spending more than an hour debugging my code. What a life haha! Thanks, Alexander!
Wow, excellent video, some of this stuff can be really confusing and isn't (AFAIK) really explained in the docs either - at least not as a whole. It's also great that you make recommendations "in passing" such as "don't destructure props" - addressing common mistakes before they happen is a great idea :-). Really a must-watch video IMHO, thanks for making it :-)
Thanks for explaining this very simply, Alexander. I especially liked all the different options because you've hit the different cases I personally used. Please keep up with this type of content. I appreciate it a lot!
Is there any overhead if we would use toRefs() compared of toRef() ? I do prefer using toRefs() and destructing that result. But I wonder if there is overhead due to it parsing all props instead just the ones you want to make reactive. Or is this negligible?
Your tutorials are very good! Would you be able to create a tutorial for writing a composable that could accept a primitive, ref, or getter? Or at least a deep dive into how vueuse or the nuxt composables handle this scenario?
After working on react for 2 years , now moving to vue and it just amazed me. But now react making huge change by bringing its compiler hope that it wont hurt vue. Xd :) Btw, Good content.
Nice tutorial! Also caution for times that objects are being passed in a component, the reactivity mechanism can end up being based on value by reference. More examples and best practices of such cases could be interesting.
I didn't know props is "reactive()" under the hood, nice! I'm surprised you didn't mention making a computed of title in the component. What's your stand here? It works, but probably not recommended?
@@TheAlexLichter why didnt u include the computed workflow in the video, then? just curious. you mean props are read only, right? refs can be changed? or am I crazy now 😂
Good question. Should've shown it too as an option, even though computed has a slight overhead (because it adds a dependency check) Yup, you are right - Updated my comment 😂
probably i should read docs, but the obvious question is: what’s the difference between computed and toRef? why didn’t you use computed? and instead used toRef?
I'd argue that it is the opposite. For me, importing ref/computed/... all the time even though it is obvious that it comes from Vue creates more noise in the code. And because TS intellisense + "go to" still works, I can easily check where things come from if needed. But you can also make it work without auto imports if you prefer it 😊
Like if you ever "lost" reactivity!
I really like your videos because they are close to real life problems.
Another big topic is avoiding losing reactivity with arrays.
Thank you so much 🙏
Good point. Will write this down for another video! 👌
The timing of this video is crazy. I was literally wrapping a prop in a ref and was wondering why my code was not behaving correctly. This video explanation was really helpful. Thank you for creating such an informative short video.
That is indeed great timing 👏🏻
Glad it helped!
When the video came out, I watched and said to myself 'meh, it's a rare case'. Here coming back after spending more than an hour debugging my code. What a life haha! Thanks, Alexander!
Oh wow! Sometimes coincidence is too real 😆
Glad it helped 👏🏻
Thanks Alex, please keep it up! I see every single video
Definitely will! Thanks for tuning in every time 🙏
Wow, excellent video, some of this stuff can be really confusing and isn't (AFAIK) really explained in the docs either - at least not as a whole. It's also great that you make recommendations "in passing" such as "don't destructure props" - addressing common mistakes before they happen is a great idea :-). Really a must-watch video IMHO, thanks for making it :-)
Thanks for explaining this very simply, Alexander. I especially liked all the different options because you've hit the different cases I personally used. Please keep up with this type of content. I appreciate it a lot!
Glad it was helpful Liran! 🙌🏻
I'm French.
Your content is so qualitative!
Thank you so much!
@unseriousdev oui oui baguette 😋
Thank you for tuning in! Gald it helps 🙌✨
high value videos -some of the best most consice vue/nuxt content out there
Thank you so much 🙏🏻
wowowow bro you are a gem its solved alot of issues of my vue app :) where were you thanks for the tip
Glad you found this channel 🙏🏻
I must say, awesome content! keep going great, Alexander!
Thanks, will do for sure! 🔥
Is there any overhead if we would use toRefs() compared of toRef() ?
I do prefer using toRefs() and destructing that result. But I wonder if there is overhead due to it parsing all props instead just the ones you want to make reactive.
Or is this negligible?
Nah, toRefs is fine as long as you don’t have optional values. Then, restructuring might not work as expected 😊
Hey Alex thanks a lot the great video. I’m still confused about what is the difference between props.title vs ()=> props.title
Your tutorials are very good! Would you be able to create a tutorial for writing a composable that could accept a primitive, ref, or getter? Or at least a deep dive into how vueuse or the nuxt composables handle this scenario?
Thank you! Yes, absolutely. Noted down 👌
Thanks covering this, love it when you show common pitfalls! Even with vue experience I keep making some of these :)
You are welcome! Glad it is helpful 🙌
Thabk you this solved my problem.
Realle good videos, keep it going this ir helpful in many ways
😊😊
Awesome!
Happy to hear they help 🙏
After working on react for 2 years , now moving to vue and it just amazed me. But now react making huge change by bringing its compiler hope that it wont hurt vue. Xd :) Btw, Good content.
Glad to hear that the switch to Vue was fun to you 👍🏻
Thank you ☺️
Nice tutorial!
Also caution for times that objects are being passed in a component, the reactivity mechanism can end up being based on value by reference. More examples and best practices of such cases could be interesting.
Good point! It is general JS behavior but can still shoot you in the foot 🙈
Would a computed() value work the same as toRef()?
Yes, absolutely! And that'd also be my "go to" version when dealing with props or `reactive` values - especially as props are read-only anyway 👌
I didn't know props is "reactive()" under the hood, nice! I'm surprised you didn't mention making a computed of title in the component. What's your stand here? It works, but probably not recommended?
Yeah, `computed` would be my go-to solution here as props are read-only anyway!
@@TheAlexLichter why didnt u include the computed workflow in the video, then? just curious.
you mean props are read only, right? refs can be changed? or am I crazy now 😂
Good question. Should've shown it too as an option, even though computed has a slight overhead (because it adds a dependency check)
Yup, you are right - Updated my comment 😂
Great explanation Alex! Made complete sense!
Glad it was helpful! 🙏🏻
probably i should read docs, but the obvious question is: what’s the difference between computed and toRef? why didn’t you use computed? and instead used toRef?
Computed would be my go-to for props.
When having other reactives, toRef allows to sync between the values in both ways!
@@TheAlexLichter ooh, i didn’t know that, thank you!
Which title will be considered in template, props.titile or toRef(...)
The more explicit one (so const title > props.title) in the template
nice information not many people talk about this simple but important concept.♥♥♥
Glad you think so!
Thank for the video, really useful. I wonder is there a way to use somehow toRefs to not lose reactivity?
From experience, toRefs can be used with the output of defineProps, which then would make all props reactive if you use the output of toRefs.
You are welcome!
With toRefs, you won't lose the reactivity (as shown) ✔
toRef is useful for *optional* props (which are not covered via toRefs if they don't exist)!
🔥🔥
Nice video as always but the example with title passed as props and then mutated thanks to toRef is not the best as props shouldn't be mutated.😊
Yes, that's true! Also mentioned that in the comments before. On the other hand, a `computed` is less performant (+ there is the readonly helper)
An Other great video ty Alex
Thank you! 🙏
Wonder if we ever gonna get a simpler ref vs reactive | useFetch vs $fetch.
Its not very intuitive for most beginners.
Great idea Damian! Will put it on the list 👌
This solves a lot of my problems 😂.
Perfect 🙌
Thanks a lot
Exactly.... We shouldn't destructuring the props 💯, i used to do in my initial days🤦😂
And you will be able to again in Vue 3.5 with the (in 3.4 experimental) props destructuring feature 👀
@@TheAlexLichter so props destructuring won't lose the reactivity in vue 3.5 feature?🤔
@freekeys yup! Check out the RFC @ github.com/vuejs/rfcs/discussions/502
@@TheAlexLichter so pinia would also do it, current i need to use storeToRef in pinia. 🤦😂
I still would go for storeToRefs because you get refs, not „reactive“
auto import is not quite good. other devs will have a headache debugging or reading the code.
I'd argue that it is the opposite. For me, importing ref/computed/... all the time even though it is obvious that it comes from Vue creates more noise in the code. And because TS intellisense + "go to" still works, I can easily check where things come from if needed.
But you can also make it work without auto imports if you prefer it 😊
I think you're left-handed 5:10
I think you are right 😁
the .value thing is so annoying sometimes :/
I actually think it is useful
When using TS the IDE should autocomplete it 🙌🏻
And then you know if the value you deal with is reactive or not 👌🏻