100% aligned with you, I am also only using refs, I find them much more handy than reactive. Until today I didn`t really understand why we have both, after you said "Now you are wondering, when would I use which?" I was expecting different situations where reactive is more useful than ref, but was surprised you`re handling it the same way by just using refs 😂👍🏼
But generally yeah, agree. If ref() uses reactive() for objects under the hood, there is no need to use both of them. Just use ref() all the time and that's all :)
@@xilass Because it requires objects to pass. And you will not always want to pass objects, but sometimes primitives as well. ref() gives you this flexibility to pass primitives and objects. reactive() not
@@xilass javascript is not used for speed... thinking about speed and premature optimization is meaningless... i laugh everytime i see someone trying to convince everyone to use fastify instead of express... those milliseconds u shave off doesnt give you anything, the speed and performance comes from database, not the api lol... node is made for scaling horizontally... so it makes no sense for anyone to re-write their infra from express to fastify or something else for miniscule or almost non-existent gains... ref is nice and short , .. well vue macros is a new thing ; ] more interesting stuff, not sure if its shown in this channel... // ✅ won't lose reactivity with destructuring const { foo, bar } = definePropsRefs() // ⬇ Ref console.log(foo.value, bar.value)
ref() when I want to replace (.value = ) the whole object later, and/or the structure is not fixed. reactive() when the object never gets replaced as a whole, its structure is fixed, and only members get accessed.
Vue introduced reactivity transform to get rid of the necessity to write ".value" all the time. $ref, $computed, etc. - "reactivityTransform: true" in the vue object of your vite config.
@@metalsadman Which is a shame, as the code is so much more readable. I have only one bigger Vue project left, before I completely switch to Svelte. Development of Vue is just disappointing.
@@Murmeltier same here. Vue3 really disappointing. Not the reactivity, but overall many bs features and inconsistency like with v-bind now accepting hidden props as event handlers, lack of .native modifier (now u don't know what does @click do) etc etc etc. Vue2 was far more consistent. We'll see if Evan does his homework and fixes those issues, if not we gonna switch to svelte too
Totally agree with your opinion. I also use ref 100% of the time for the same readability reason. Not to mention that the ide adds .value if it's properly configured!
As a team we also noticed that reactive can make unnecessary mutations indeed, let say you have basic company object ( name, phone, website etc ) and you have watcher/computed based on company reactive object. If you changed something in the reactive data, watchers and computed values triggered (even if you are not watching or computing the changed value )
Because with a ref, you can reactively change the whole object, with reactive, you can only change members of the object. So a ref makes it also easy to hold dynamically loaded data for example that replace the whole object.
I also always use refs, but, I think you can always have a variable called "const state = reactive({...})" which also makes it very clear what data is reactive and which isn't. Then, this is also easy to replace by pinia in the future
I use ref when i want to change/assign a new object/value later, i use reactive when only need to change it's property, because when we assign a new object to a reactive variable it becomes unreactive. In fact reactive should be constant.
Deep reactivity will not work if you use ref for multilevel nested objects. Simple rules are, use reactive for non primitive data and ref for primitive data (let me know if my knowledge is outdated lol)
I always use ref, but i wrote a vue.js plugin, and data is not reactive, when I use this plugin in other applications if I want to update reactive state, for examle: const state = reactive({}) and I want change it to: state = {name: ''some", age: 24} How can I do this?
Better late than never 😅. You can't reassign reactive. Try with: state.name = "some"; state.age = 24; or: Object.assign(state, { name: "some", age: 24 }); ...or just use ref for everything and don't worry about reactive limitations 🤷.
Hmmm. Is there someplace you read this? I'd love to see their reasoning. But in general, whether they're talking about refs (reactive data) or template refs, both work just fine inside v-for loops. Here's an example code snippet I made: learnvue.co/2021/06/the-beginners-guide-to-vue-template-refs-with-vue-3-updates/#using-vue-templates-refs-with-a-v-for-loop
If what you mean calling ref() to define a new instance of Ref inside the template, then they are right. We shouldn't do that. If what you mean using an already defined ref in the template, they are wrong. The difference is "instancing a Ref in the template" vs "reading a ref in the template" .
I believe ref does not use reactive under the hood. There is a really nice video un Vue Mastery that explains so. reactive uses proxies, leveraging the get and set method to call track and trigger respectively, running effects that change the state. ref uses object accessors, achieving the same result using the get and set object accessors. It does not go like: function ref(v) { return reactive({value: v}) } At least this is what I understood, it is true that when you console log a ref you see the word proxy, so I might be wrong. This is an interesting topic, does anyone have knowledge of the vue source code to explain/confirm?
General advice, never use reactive. Always use ref, ref with object inside gets wrapped with a reactive anyway. So no need for reactive. But u benefit code consistency. Thank me later.
100% aligned with you, I am also only using refs, I find them much more handy than reactive. Until today I didn`t really understand why we have both, after you said "Now you are wondering, when would I use which?" I was expecting different situations where reactive is more useful than ref, but was surprised you`re handling it the same way by just using refs 😂👍🏼
from what ive seen from most developers, the pattern of only using ref is pretty prevalent across the Vue community right now so we’re not alone!
But generally yeah, agree. If ref() uses reactive() for objects under the hood, there is no need to use both of them. Just use ref() all the time and that's all :)
In my view, why use ref if you can use directly reactive? Its one less step, less compute
@@xilass Because it requires objects to pass. And you will not always want to pass objects, but sometimes primitives as well. ref() gives you this flexibility to pass primitives and objects. reactive() not
@@xilass javascript is not used for speed... thinking about speed and premature optimization is meaningless...
i laugh everytime i see someone trying to convince everyone to use fastify instead of express...
those milliseconds u shave off doesnt give you anything, the speed and performance comes from database, not the api lol... node is made for scaling horizontally...
so it makes no sense for anyone to re-write their infra from express to fastify or something else for miniscule or almost non-existent gains...
ref is nice and short , .. well vue macros is a new thing ; ]
more interesting stuff, not sure if its shown in this channel...
// ✅ won't lose reactivity with destructuring
const { foo, bar } = definePropsRefs()
// ⬇ Ref
console.log(foo.value, bar.value)
@@Microphunktv-jb3kj man, i fully forgot what is ref and reactive since then 😓
Sometime ill back to see vue/nuxt scenario
ref() when I want to replace (.value = ) the whole object later, and/or the structure is not fixed. reactive() when the object never gets replaced as a whole, its structure is fixed, and only members get accessed.
Exactly the same usage
Vue introduced reactivity transform to get rid of the necessity to write ".value" all the time. $ref, $computed, etc. - "reactivityTransform: true" in the vue object of your vite config.
just made a video on this ;) but awesome point
and now it's deprecated, was experimental anyway.
@@metalsadman Which is a shame, as the code is so much more readable. I have only one bigger Vue project left, before I completely switch to Svelte. Development of Vue is just disappointing.
@@Murmeltier what's your opinion on Vue, Svelte after a year?
@@Murmeltier same here. Vue3 really disappointing. Not the reactivity, but overall many bs features and inconsistency like with v-bind now accepting hidden props as event handlers, lack of .native modifier (now u don't know what does @click do) etc etc etc.
Vue2 was far more consistent.
We'll see if Evan does his homework and fixes those issues, if not we gonna switch to svelte too
Totally agree with your opinion. I also use ref 100% of the time for the same readability reason. Not to mention that the ide adds .value if it's properly configured!
good point, definitely right now, im using ref but who knows with future versions when patterns will change!
As a team we also noticed that reactive can make unnecessary mutations indeed, let say you have basic company object ( name, phone, website etc ) and you have watcher/computed based on company reactive object. If you changed something in the reactive data, watchers and computed values triggered (even if you are not watching or computing the changed value )
Actuallu reactive makes all nested props reactive so if u only want to make top level props reactive u can make a shallow reactive object...
What a nice and clear description. the examples help me understand the difference, thanks.
thank you!
I recently discovered your channel.
I find it VERY informative and well paced
Thank you
Because with a ref, you can reactively change the whole object, with reactive, you can only change members of the object. So a ref makes it also easy to hold dynamically loaded data for example that replace the whole object.
I also always use refs, but, I think you can always have a variable called "const state = reactive({...})" which also makes it very clear what data is reactive and which isn't. Then, this is also easy to replace by pinia in the future
issue with this approach though, is that in the templates you endup using a lot of `{{ state.myVar }}`
sir what is your vs code theme
I thought it was only me who always uses ref because having .value makes it easier to read that it is a reactive object. 😁
I use ref when i want to change/assign a new object/value later, i use reactive when only need to change it's property, because when we assign a new object to a reactive variable it becomes unreactive. In fact reactive should be constant.
Thanks!
How to reactive method and have argument like method in options api?
I prefer to use reactive for objects and ref for others type of variables
if ref and reactive are the same, why split it?, probably vuejs team have a reason why
Same here, I use ref everywhere to have consistent code
which VSCode color theme is this?
Thanks! I loose so much time because of missunderstanding this concept of reactivity!
I and my team use ref 100%, basically, when you see .value, you will known that variable is a ref instanlly.
Faster reading speed.
Deep reactivity will not work if you use ref for multilevel nested objects. Simple rules are, use reactive for non primitive data and ref for primitive data (let me know if my knowledge is outdated lol)
Hello sir, how do you watch an ref object changing in vue3
I always use ref, but i wrote a vue.js plugin, and data is not reactive, when I use this plugin in other applications
if I want to update reactive state, for examle:
const state = reactive({})
and I want change it to:
state = {name: ''some", age: 24}
How can I do this?
Better late than never 😅. You can't reassign reactive. Try with:
state.name = "some";
state.age = 24;
or:
Object.assign(state, { name: "some", age: 24 });
...or just use ref for everything and don't worry about reactive limitations 🤷.
I was told not to use ref() within v-for loops... what would be the reason?
Hmmm. Is there someplace you read this? I'd love to see their reasoning. But in general, whether they're talking about refs (reactive data) or template refs, both work just fine inside v-for loops. Here's an example code snippet I made: learnvue.co/2021/06/the-beginners-guide-to-vue-template-refs-with-vue-3-updates/#using-vue-templates-refs-with-a-v-for-loop
If what you mean calling ref() to define a new instance of Ref inside the template, then they are right. We shouldn't do that. If what you mean using an already defined ref in the template, they are wrong.
The difference is "instancing a Ref in the template" vs "reading a ref in the template" .
I was: "oh cool I'll find a reason to use reactive". Nope I feel relived that a lot of people don't use reactive.
Very timely! I feel like this has been hot topic recently
Definitely! Glad you think so
Its only semantic sugar for saving the "value" detour.
So what's the difference between the two? Their name?
I believe ref does not use reactive under the hood. There is a really nice video un Vue Mastery that explains so.
reactive uses proxies, leveraging the get and set method to call track and trigger respectively, running effects that change the state.
ref uses object accessors, achieving the same result using the get and set object accessors. It does not go like:
function ref(v) {
return reactive({value: v})
}
At least this is what I understood, it is true that when you console log a ref you see the word proxy, so I might be wrong.
This is an interesting topic, does anyone have knowledge of the vue source code to explain/confirm?
So in the end, you did not clearly tell when to use ref versus reactive, saying "I use refs 100% of time" ahah it is not good reasoning
Same here. I tend to use refs 100% of the time, for the exact same reasons you mentioned!
i use ref all the time
I use "ref() " because it's shorter 😄
General advice, never use reactive. Always use ref, ref with object inside gets wrapped with a reactive anyway. So no need for reactive. But u benefit code consistency.
Thank me later.
I use ref all the time. However, I learned a new rule or thumb rule today that could help me when working with teams.
Thank you!
happy to help!
I could buy this argument if we had to also use .value in the template. But since we don't... That's just verbosity for no good reason.
No wonder web dev is a mess.
vue is a lil borked. go nuxt or react