I learned Vue and Vue 3 for the first time in early 2022 and these reactivity functions were some of the most confusing things to me. I think because it uses JS proxies under the hood; the Vue team wasn't able to get around this syntax. I looked into these macros too and decided that, in most cases, they add more complexity than they're worth. Except perhaps for some library writing ( probably a headache for something like VueUse ). Thank you for the explainer!
+1 here. This dollar sign mess is awful. However, I don't have any problems with .value and reactivity in common, it makes things obvious, you can clearly understand if the variable is reactive or not.
+10 from here. Uncovering "it uses JS proxies under the hood" is golden and "macros... add more complexity than they're worth" is pure gold. If you don't know what is the design pattern of those macros, using those $/ref/refs/reactive etc... is extremely not intuitive, unless you are looking for headache:)
Vue in general suffers from being insufficiently opinionated. Having ref + reactive + reactivitytransform, adds obscure, difficult-to-reason about syntax.... to what end? Save a few characters? All the $$ stuff makes it clear that this doesn't even abstract anything away from you; you still have to be very careful to not break reactivity. God forbid different developers mix the $ and ref styles within a codebase. Pick a best practice. Use only ref always. Be explicit about .value since JS reactivity is always a leaky abstraction, even (especially?) with reactivity transform.
I think, the simplest way to use a reactivity is just using ref as you've shown in the second example. Yes, you need to deal with .value, but in fact it's not a big problem. It just depends on the preferences.
I never had a problem with adding the .value to manipulate the ref's value. These compile time macros look cool, but they add some magic that doesn't read as well as just using the API of ref, especially the $$ syntax is super weird for me.
If you are writing a complex app, the Composition API allows you to keep concerns like “data” and “methods” close together, and promotes code reuse through composable functions (“use” functions). That’s all very cool, and very useful! But… For the majority of simple components I’ve written, the Options API is just easier. Plus, for new developers, the Options API’s rigid structure provides, well, *structure*! I like that we can use both the Composition and Options APIs. They each have their use cases.
Great explanation and examples Eric, you are a natural teacher. While i can see the benefits of using $ and $$, from a readability perspective i find them unintuitive and confusing... more like syntatic salt than syntactic sugar.
I am using nuxt and vuetiify now to build stuff. It feels way nicer than this. I built a few apps with react, svelte and angular and now I'm trying to use vue because I've heard it's the simplest of the big 3, but I feel like maybe that was the case before and they are trying to add all the cool modern stuff and completely changing things in major releases. It confuses me when I'm googling problems. All the magic it does behind the scenes makes it harder to grasp. Angular is known as the most complicated, but at this day I would call it simplest of the 3 to grasp because you can figure out everything that is going on. It is very explicit. And svelte feels like the simple amazing one at the moment. What do you think of the differences? Are they complicating our lives with new releases or making them easier?
Great explanation , and Thank you so much for the explanation. How can we show modal popup with a div tag(textbox and button) in it, using ref in Vue3 and Bootstrap 5. Could you please share some suggestions on this. It will help me a lot . Thanks in advance
i've been working on (learning) Vue 3 on a customisable dashboard project using Pinia. The ref/reactive was/is a pain point for me, especially when it comes to overwriting entire objects, as a lowly beginner this was very confusing.
I'm struggling to understand why he faced this problem in the first place. Why would someone write the Vue component's script block this way and not keep the variables in the "data" block where they already are reactive...?
I guess because it's not just the data block, if you're using the option api, you also have to make blocks for everything else, methods, computed, and so on. That's a lot of lines for nothing and sometimes you have to makes variables reactive so they can be accessed from 2 methods. Whereas the composition api allows you to make non-reactive variables and use them everywhere you want.
Thanks. Would love to see another video about reactivity in Vue 2.7 along with a comparison of composition api between 2.7/3. This would be helpful with migrations.
Thanks for your showcase Erik. I prefer using ref and shallowRef only and always add .value because less compiler magic usually leads to better code imho. But The vue team definetly does a great job introducing convenience features for simpler use cases. For libraries I would stay away from using such features until they are polished enough :)
At 5:40 can you do a spread, so msg = {...newNum}, where newNum = {num: 15}? And if so would something like num = 10; msg = {...{num}}?
Рік тому+1
You did not mentioned that reactive will update render just for properties which are updated and if you have object in ref, it will update whole render.
Vue is moving toward Svelte way of handling state, because with Svelte a state is simply a variable, we dont need to import 'ref' or 'useState', we simply do let msg = 'message' and it is automatically equipped reactivity feature, I assume all frameworks are mimicing Svelte/Sveltekit 😘
I’m gonna be honest here, I see that a lot of people like vue and think it’s really intuitive. And I think many points are fair. But are there really people out there that say: “Yeah, this is better than React”? I’m quite confused by the many different ways to achieve reactivity, but then again, if you destructure it, you might lose that reactivity and need $-signs, or .value or whatever, depends on the implementation. I think vue has a lot of good stuff, but React’s implementation of state seems so much better and with less pitfalls. Also, at 12:47, Erik talked about a “store”. From my understanding this will still create new state for each component. Or is there some magic happening so that’s global, shared state?
I think it's a cool way to do things in Vue, but ... Reactvity Transform is still an experimental feature of Vue 3. So it's "risky" to use it in production. It would be nice if the Vue team made it permanent, but we don't know what will really happen. Cool video. Thanks for sharing it! Blessings from Venezuela, and happy new year 🤗
I think that definitely, the Composition API and the "script setup" are the most "Vue" way to write code. Less code, clearer, cleaner... more Vue. I'm just learning Laravel 9, but Vue code I prefer to write with the Composition API. Greetings!
*Important note:* This feature will be removed from Vue. But you will probably be able to use it again via plugin. Personally, I would not necessarily do that and can understand the reasons why this function is removed.
Vue3 got less intuitive than Vue2 with these .values. I can see why it went the way that it did, but it lost some of Vue2's magic. Thanks for this video, it helped clarify some things and showed some nice tricks.
Exactly! Now there are 3 different ways to use reactive variables (and you can mix them in one project) - and joining to new a project made by other people will be a nightmare
importing useSuperHero from useName when neither uses anything is peak react seeping into everything. I don't get the fascination with slapping the "use" prefix on absolutely every method, function or file name
$() $$() It is odd isn't it? Look like JQuery if you want to do this you have to use $$ if you want to do that, please use $() ohhh I think it is not pretty good feature the Vue core team must think how to simlify the framework vue instead of making it more complecated. Vue must be predictable and easy to learn and understand. In the framework too many ways how to create reactive variable It is useless and can bother other developers. One developer likes REF other REACTIVE other $REF what is the hell
IMO especially for consistency in a group use Ref always......would be a lot less confusing you will just have to remember in scripts to do `.value`. I don't want to ever think about having to do `.ToRef()`
I am honestly not sure what problems the $ addresses. I have worked with a decent number of Vue applications and faced no problems with the .value . Maybe I am just set in my ways, but I prefer the .value to the newly proposed $ method.
It's just a vue-only thing that isn't so intuitive, especially if coming from Vue2. Having to add .value everywhere is just more typing and pretty ugly imo. If I had learned it this way initially, I'd probably be feeling the same way you are. But once you learn it, and accept it, it's fine. Just an initial learning curve and mindshift.
I don't know why he said it was a "problem" per se. It's syntactic sugar for people who like to write less code. I am in the same boat. I prefer writing .value because $ reminds me too much of jQuery.
Early on vue really ate reacts lunch when it came to the quality of their API but all this special character, obfusticated variable types nonsense makes for a terrible interface. React is treating primitive JavaScript objects in the right way and this is getting further away from that.
With ref and reactive, Vue has lost one of it's main benefit, small learning curve. Also Vue dev tools doesn't work properly. Till now I have only used Vue but now I'm thinking of shifting to react or enjoy svelte. One thing Vue developers could do is make every variable with $ sign as reactive property, hence completely eliminating the use of ref and reactive from beginners standpoint. For eg $first_name, $useSuperhero() I kindly request to Vue developers to not make it complex just for the top developers. There are low level developers also.
Didn't like it at all, confusing. Using composables that return refs wrapped in object and have no problem with .value efforts. Worries me a bit as it doesn't seem to be a right direction.
"Stop using .value" is a good title because call to my attention but at the same time it is a clickbait (no offense please) because there is nothing bad using ref(type). In fact, ref and Ref are more powerful because I can define variables in TypeScript like this: const myVar: Ref = ref(null); Of course, we are obligated to use myVar.value but this is a small price to pay for.
Well I'm a new to Vue and to be completely honest I'd be just fine with the `.value` thing. All the trouble and gotchas you need to go to have to avoid the `.value` is too much
@@ProgramWithErik "Vue 2.7, which was shipped in July 2022, is the final minor release of the Vue 2 version range. Vue 2 has now entered maintenance mode: it will no longer ship new features, but will continue to receive critical bug fixes and security updates for 18 months starting from the 2.7 release date. This means Vue 2 will reach End of Life on December 31st, 2023."
This video doesn't explain, why someone should even consider this experimental featue which provides nothing new. Maybe it's just useless. This video at least doesn't give a reason that justifies "Stop Using ...". Quite bad ...
He's just feeding the algorithm. Click-batey titles for engagement. Reactivity Transform has been dropped, I hope he updates everyone about this. I have a good eye for when a feature is a code smell and I knew this feature wouldn't be welcomed. In the other hand, the defineModel, generics, defineSlot, defineOptions, are amazing. And Nuxt with the auto import everything (stores, layouts, pages, components, stores and custom directories, server api paths completion) it's even better!
I learned Vue and Vue 3 for the first time in early 2022 and these reactivity functions were some of the most confusing things to me. I think because it uses JS proxies under the hood; the Vue team wasn't able to get around this syntax. I looked into these macros too and decided that, in most cases, they add more complexity than they're worth. Except perhaps for some library writing ( probably a headache for something like VueUse ).
Thank you for the explainer!
+1 here. This dollar sign mess is awful. However, I don't have any problems with .value and reactivity in common, it makes things obvious, you can clearly understand if the variable is reactive or not.
+10 from here. Uncovering "it uses JS proxies under the hood" is golden and "macros... add more complexity than they're worth" is pure gold. If you don't know what is the design pattern of those macros, using those $/ref/refs/reactive etc... is extremely not intuitive, unless you are looking for headache:)
Vue in general suffers from being insufficiently opinionated. Having ref + reactive + reactivitytransform, adds obscure, difficult-to-reason about syntax.... to what end? Save a few characters? All the $$ stuff makes it clear that this doesn't even abstract anything away from you; you still have to be very careful to not break reactivity. God forbid different developers mix the $ and ref styles within a codebase.
Pick a best practice. Use only ref always. Be explicit about .value since JS reactivity is always a leaky abstraction, even (especially?) with reactivity transform.
I think, the simplest way to use a reactivity is just using ref as you've shown in the second example. Yes, you need to deal with .value, but in fact it's not a big problem. It just depends on the preferences.
I never had a problem with adding the .value to manipulate the ref's value. These compile time macros look cool, but they add some magic that doesn't read as well as just using the API of ref, especially the $$ syntax is super weird for me.
If you are writing a complex app, the Composition API allows you to keep concerns like “data” and “methods” close together, and promotes code reuse through composable functions (“use” functions). That’s all very cool, and very useful! But…
For the majority of simple components I’ve written, the Options API is just easier. Plus, for new developers, the Options API’s rigid structure provides, well, *structure*!
I like that we can use both the Composition and Options APIs. They each have their use cases.
Yes, simple components, stick to Options API.
So interesting. It is the big change between vue 2 and vue 3!
Great explanation and examples Eric, you are a natural teacher. While i can see the benefits of using $ and $$, from a readability perspective i find them unintuitive and confusing... more like syntatic salt than syntactic sugar.
Glad it was helpful! I understand it's a little confusing.
I am using nuxt and vuetiify now to build stuff. It feels way nicer than this. I built a few apps with react, svelte and angular and now I'm trying to use vue because I've heard it's the simplest of the big 3, but I feel like maybe that was the case before and they are trying to add all the cool modern stuff and completely changing things in major releases. It confuses me when I'm googling problems. All the magic it does behind the scenes makes it harder to grasp. Angular is known as the most complicated, but at this day I would call it simplest of the 3 to grasp because you can figure out everything that is going on. It is very explicit. And svelte feels like the simple amazing one at the moment. What do you think of the differences? Are they complicating our lives with new releases or making them easier?
All of this just makes me miss Vue 2 😂
I prefer using refs and calling the value method. It lets me know at a glance that the object I'm working with is reactive.
Great explanation , and Thank you so much for the explanation.
How can we show modal popup with a div tag(textbox and button) in it, using ref in Vue3 and Bootstrap 5. Could you please share some suggestions on this. It will help me a lot . Thanks in advance
I don't want to type .value and still have the reactivity without the overhead, not possible with vue?
what version are you using ?
i've been working on (learning) Vue 3 on a customisable dashboard project using Pinia. The ref/reactive was/is a pain point for me, especially when it comes to overwriting entire objects, as a lowly beginner this was very confusing.
I have to use vue because I just began to work on a new project. But that $ magic looks like something I don’t want to see ever again
I'm struggling to understand why he faced this problem in the first place. Why would someone write the Vue component's script block this way and not keep the variables in the "data" block where they already are reactive...?
I guess because it's not just the data block, if you're using the option api, you also have to make blocks for everything else, methods, computed, and so on.
That's a lot of lines for nothing and sometimes you have to makes variables reactive so they can be accessed from 2 methods. Whereas the composition api allows you to make non-reactive variables and use them everywhere you want.
Thanks. Would love to see another video about reactivity in Vue 2.7 along with a comparison of composition api between 2.7/3. This would be helpful with migrations.
This was eventually deprecated so I don't recommend it for new learners, but I appreciate Erik taking the time to go over it.
Thanks for your showcase Erik.
I prefer using ref and shallowRef only and always add .value because less compiler magic usually leads to better code imho.
But The vue team definetly does a great job introducing convenience features for simpler use cases.
For libraries I would stay away from using such features until they are polished enough :)
At 5:40 can you do a spread, so msg = {...newNum}, where newNum = {num: 15}? And if so would something like num = 10; msg = {...{num}}?
You did not mentioned that reactive will update render just for properties which are updated and if you have object in ref, it will update whole render.
Well, in my opinion..
I'd prefer how vue 2 treat data / value in a simplest way..
Vue 3 make me learn Vue start from all over again.
Vue is moving toward Svelte way of handling state, because with Svelte a state is simply a variable, we dont need to import 'ref' or 'useState', we simply do let msg = 'message' and it is automatically equipped reactivity feature, I assume all frameworks are mimicing Svelte/Sveltekit 😘
It’s not a bad way to go
Does svelte do any tree-shaking for non-reactive variables? I could see that creating a lot of bloated code when building.
Sometimes I want to make a variable without reactivity, because its not needed. So there should be a way to explicitly make something reactive or not.
@@yourivanmill Yah, simply put 'const' in front of a variable and this makes it non-reactive 😌
@@Vietnamkid1993 nope, compiled codes are clean and simple, of course it does tree-shaking 😌
I’m gonna be honest here, I see that a lot of people like vue and think it’s really intuitive. And I think many points are fair. But are there really people out there that say: “Yeah, this is better than React”? I’m quite confused by the many different ways to achieve reactivity, but then again, if you destructure it, you might lose that reactivity and need $-signs, or .value or whatever, depends on the implementation. I think vue has a lot of good stuff, but React’s implementation of state seems so much better and with less pitfalls. Also, at 12:47, Erik talked about a “store”. From my understanding this will still create new state for each component. Or is there some magic happening so that’s global, shared state?
Great looking background. 👌
Thank you! Cheers!
I like your lego. I think you are right, looks kind of awesome.
i use reactive every time i can. i feel like the $ is makes your code a little less readable. not sure if i am going to use it.
Thanks for the video. It was helpful. Reactivity sure has got complicated, throw in nuxt 3 and it seems to get worse
I think it's a cool way to do things in Vue, but ... Reactvity Transform is still an experimental feature of Vue 3. So it's "risky" to use it in production. It would be nice if the Vue team made it permanent, but we don't know what will really happen.
Cool video. Thanks for sharing it!
Blessings from Venezuela, and happy new year 🤗
Yeah, it was supposed to be out in 3.3 , but it seems it has been pushed
just going to be honest, I find the options API cleaner, then again I am a Laravel(PHP)+JS developer, not a "pure" JS developer
I think that definitely, the Composition API and the "script setup" are the most "Vue" way to write code. Less code, clearer, cleaner... more Vue.
I'm just learning Laravel 9, but Vue code I prefer to write with the Composition API.
Greetings!
This feature has been dropped in version 3.4
Only JavaScript lol
*Important note:* This feature will be removed from Vue. But you will probably be able to use it again via plugin. Personally, I would not necessarily do that and can understand the reasons why this function is removed.
@programwitherik I think it's a good idea if you update the description of the video, or add a card or something.
The fewer the plugins, the better. So the takeaway of this video is do the opposite and use value?
I like your lego set :D and thanks for the video.
Thanks for watching!
Just an FYI, if you look at the docs about the Reactivity Transform, this experimental feature was removed.
Vue3 got less intuitive than Vue2 with these .values. I can see why it went the way that it did, but it lost some of Vue2's magic. Thanks for this video, it helped clarify some things and showed some nice tricks.
Exactly! Now there are 3 different ways to use reactive variables (and you can mix them in one project) - and joining to new a project made by other people will be a nightmare
Fair enough!
importing useSuperHero from useName when neither uses anything is peak react seeping into everything. I don't get the fascination with slapping the "use" prefix on absolutely every method, function or file name
$() $$() It is odd isn't it? Look like JQuery if you want to do this you have to use $$ if you want to do that, please use $() ohhh I think it is not pretty good feature the Vue core team must think how to simlify the framework vue instead of making it more complecated. Vue must be predictable and easy to learn and understand. In the framework too many ways how to create reactive variable It is useless and can bother other developers. One developer likes REF other REACTIVE other $REF what is the hell
Server is running correctly but I got an type error(ts2552) with $ref on vscode!
That is weird... oh yeah, make sure you turn the feature on in you config.
I’m not a fan of $ syntax, i prever .value since it’s easier to understand even thought i’ll have to write extra code
Why can't I use $ref in nuxt3 project?
IMO especially for consistency in a group use Ref always......would be a lot less confusing you will just have to remember in scripts to do `.value`. I don't want to ever think about having to do `.ToRef()`
So reactive is just ref with extra steps?
Other way around. ref is a reactive that exposes a value property.
Adding ".value" is a cue for myselt that yeaah, "that value" is definitely reactive.
Less magic is always better. And ts helps to know what is what.
Awesome, thanks
You bet!
Ty for video! Pls stop scroll up and down in 14:18 ))
That's cool, I love Composition API...
Anyways, .value is not a problem for me xD
.value actually good so that we can differentiate the reactive variable or just a variable
.value is needed in the javascript but you can mutate without .value in the template
I am honestly not sure what problems the $ addresses. I have worked with a decent number of Vue applications and faced no problems with the .value . Maybe I am just set in my ways, but I prefer the .value to the newly proposed $ method.
It's just a vue-only thing that isn't so intuitive, especially if coming from Vue2. Having to add .value everywhere is just more typing and pretty ugly imo. If I had learned it this way initially, I'd probably be feeling the same way you are. But once you learn it, and accept it, it's fine. Just an initial learning curve and mindshift.
I don't know why he said it was a "problem" per se. It's syntactic sugar for people who like to write less code. I am in the same boat. I prefer writing .value because $ reminds me too much of jQuery.
Very complex. I would say, Svelte uses smarter syntax.
I didn't explain it very well on this. I'll make a follow up video.
I do mind the .value - and as soon as your app gets closer to enterprise scale you will too.
Hell of a lot more confusing with $ than just using .value
Early on vue really ate reacts lunch when it came to the quality of their API but all this special character, obfusticated variable types nonsense makes for a terrible interface. React is treating primitive JavaScript objects in the right way and this is getting further away from that.
reactive uses ref under the hood I'm pretty sure. I haven't really found a specific case for only using reactive.
Lol, ref using reactive
That’s a good point , I have a soft spot for Reactive though
Such an overenginnering just for nothing, lmao
With ref and reactive, Vue has lost one of it's main benefit, small learning curve.
Also Vue dev tools doesn't work properly.
Till now I have only used Vue but now I'm thinking of shifting to react or enjoy svelte.
One thing Vue developers could do is make every variable with $ sign as reactive property, hence completely eliminating the use of ref and reactive from beginners standpoint.
For eg $first_name, $useSuperhero()
I kindly request to Vue developers to not make it complex just for the top developers. There are low level developers also.
Sorry to hear that. I probably could have explained this better. Don't give up on it!
Options API: look at all the hoops they have to jump through just to mimic a fraction of our power!!!
It gets better
a mess with $'s
dollar sign frenzy
Remove .value simply confuse us whether it is reactive variable or not. No doubt code shorter
Didn't like it at all, confusing. Using composables that return refs wrapped in object and have no problem with .value efforts. Worries me a bit as it doesn't seem to be a right direction.
"Stop using .value" is a good title because call to my attention but at the same time it is a clickbait (no offense please) because there is nothing bad using ref(type). In fact, ref and Ref are more powerful because I can define variables in TypeScript like this:
const myVar: Ref = ref(null);
Of course, we are obligated to use myVar.value but this is a small price to pay for.
I still think this $ feature, will make who doesn't understand reactivity feel more confuse.
Well I'm a new to Vue and to be completely honest I'd be just fine with the `.value` thing. All the trouble and gotchas you need to go to have to avoid the `.value` is too much
Warning! Reactivity Transformed is being dropped by Vue in the coming months
Great video.. but $$ .. and toRef.. definitely its a mess
update, removed from core 3.4 but still available as a package
Reactivity transform depreciated. Lmao
Rest in peace Vue.js 😢
It's not dead yet!
@@ProgramWithErik "Vue 2.7, which was shipped in July 2022, is the final minor release of the Vue 2 version range. Vue 2 has now entered maintenance mode: it will no longer ship new features, but will continue to receive critical bug fixes and security updates for 18 months starting from the 2.7 release date. This means Vue 2 will reach End of Life on December 31st, 2023."
Oh god. Keep things simple. :(
I will.
This one was rejected by Evan so everyone beware, don't use this. A Vue macro is available for it if really needed but probably not a good idea.
But you dont explain what a $ or a $$ does, or why inside a function. If I dont understand it, i prefer the known way.
I'll make a follow up video on this. Sorry about that.
@@ProgramWithErik Cool. Thanks
Delete this video. $ref has been decidedly removed as a feature
I literally never use reactive
This video doesn't explain, why someone should even consider this experimental featue which provides nothing new. Maybe it's just useless. This video at least doesn't give a reason that justifies "Stop Using ...". Quite bad ...
He's just feeding the algorithm. Click-batey titles for engagement.
Reactivity Transform has been dropped, I hope he updates everyone about this.
I have a good eye for when a feature is a code smell and I knew this feature wouldn't be welcomed.
In the other hand, the defineModel, generics, defineSlot, defineOptions, are amazing. And Nuxt with the auto import everything (stores, layouts, pages, components, stores and custom directories, server api paths completion) it's even better!
Composition api looks not so good. I think this is the main reason that vue is loosing popularity
They will be removing this feature in 3.4
Yup, this is an older video!
The feature has unfortunately been dropped.
Which one?
$ref@@ProgramWithErik
I will use it or not, but it was interesting. Thanks.
I loved Vue for its simplicity. They turned really wrong corner. 🥲
Um. I'm going to make a follow up of this video. I think it came off too confusing.