Avoid losing Reactivity in your Vue Application
Вставка
- Опубліковано 9 лип 2024
- 🔄 Reactivity is a crucial and and concept when building any kind of Vue application. But especially with the Composition API, I see more and more people having trouble with Reactivity and ensure that the "reactivity chain" will be kept up throughout various composables and components. In this video, I want to highlight typical issues with ref's and reactive that I've seen throughout the applications.
Key points:
🎛️ Understand how Reactivity is tracked and "when it is lost"
👩💻 Diving into ref, props and thus, reactive.
✨ Various examples to "fix" reactivity.
---
Links:
🔗 Docs - vuejs.org/guide/essentials/re...
🔗 Code - github.com/manniL/alexander-l...
Don't forget to hit that "Subscribe" button, ring the notification bell and give a thumbs up!
🌐 Connect further:
Website: www.lichter.io
Twitter/X: / thealexlichter
Twitch: / thealexlichter
Chapters:
00:00 Intro + Overview
00:52 Reactivity loss with ref's
03:48 Reactivity loss with props / with reactive
09:03 Summary
Keywords:
vue reactivity ref reactive - Наука та технологія
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! 👌
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 👏🏻
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!
Thanks Alex, please keep it up! I see every single video
Definitely will! Thanks for tuning in every time 🙏
nice information not many people talk about this simple but important concept.♥♥♥
Glad you think so!
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! 🙌🏻
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 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 🙌
I must say, awesome content! keep going great, Alexander!
Thanks, will do for sure! 🔥
high value videos -some of the best most consice vue/nuxt content out there
Thank you so much 🙏🏻
Great explanation Alex! Made complete sense!
Glad it was helpful! 🙏🏻
I'm French.
Your content is so qualitative!
Thank you so much!
🥖🥖🥖
@@unseriousdev oui oui baguette 😋
Thank you for tuning in! Gald it helps 🙌✨
Thabk you this solved my problem.
Realle good videos, keep it going this ir helpful in many ways
😊😊
Awesome!
Happy to hear they help 🙏
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 👌
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
Thanks, Alex 💚
You are welcome! 👏
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 🙈
Thanks a lot
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 😂
Which title will be considered in template, props.titile or toRef(...)
The more explicit one (so const title > props.title) in the template
🔥🔥
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)!
An Other great video ty Alex
Thank you! 🙏
This solves a lot of my problems 😂.
Perfect 🙌
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!
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 👌
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 👌🏻