Stop Using .value with ref In Vue 3! Reactivity Transformed Explained!
ฝัง
- เผยแพร่เมื่อ 3 ส.ค. 2024
- #vuejs #vue3
In vue.js there are ref and reactive. Then there are .value and the new reactivity transformed. In this video I explain in this Tutorial how reactivity transform works, how you can use ref and reactive in Vue.js!
👉Check out my last video on ChatGPT
• Can ChatGPT Write Bett...
👉 Sign up and get free Vue cheat sheets and updates!
www.vuecourse.tech
👉 Need some help with a project, level up your skills, Vuetify or Nuxt bug? Check out my 1-on-1 mentoring!'
mentorcruise.com/mentor/erikh...
Links:
vuejs.org/guide/extras/reacti...
vuejs.org/guide/extras/reacti...
0:00 Introduction
0:32 How to use ref
03:22 $ref explained reactivity transform
04:50 reactive explained
05:56 Using reactive with composables
08:50 using toRefs
09:09 using $()
09:32 using ref with composables
13:26 conclusion reactive vs ref what to use
![[LIVE] : ONE ลุมพินี 73 วันนี้!! คู่เอก "วรพล vs พันฤทธิ์"](http://i.ytimg.com/vi/rrOljlqse3A/mqdefault.jpg)
I don't mind about the .value at all. If you sort of understand why that's like that and the proxy object, I'd avoid extra magic.
This! Many developers complain online about the “Vue magic” that breaks their libraries. We need to make Vue more streamlined and easier to integrate with libraries rather than introduce new “ magic “ that solves no problems ( imo ). Is the developer experience really that bad if developers have to type .value every time they use ref?
@@khaldounal-nuaimi3594 the thing is that currently the magic is applied on the template, and not on the script, which makes it feel a bit inconsistent...
@@khaldounal-nuaimi3594 I think I would prefer all magic, or just no magic by default (too late now).
@@jonasex3001 exactly. The real problem is the inconsistent behavior.
I agree with you all. I’m still using the “all magic” options API
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 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.
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.
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.
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!
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
So interesting. It is the big change between vue 2 and vue 3!
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 :)
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.
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.
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!
All of this just makes me miss Vue 2 😂
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.
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.
This was eventually deprecated so I don't recommend it for new learners, but I appreciate Erik taking the time to go over it.
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.
*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.
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 😌
Just an FYI, if you look at the docs about the Reactivity Transform, this experimental feature was removed.
Thanks for the video. It was helpful. Reactivity sure has got complicated, throw in nuxt 3 and it seems to get worse
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?
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.
I like your lego set :D and thanks for the video.
Thanks for watching!
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
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’m not a fan of $ syntax, i prever .value since it’s easier to understand even thought i’ll have to write extra code
Awesome, thanks
You bet!
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.
I like your lego. I think you are right, looks kind of awesome.
Great looking background. 👌
Thank you! Cheers!
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()`
update, removed from core 3.4 but still available as a package
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}}?
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.
Adding ".value" is a cue for myselt that yeaah, "that value" is definitely reactive.
That's cool, I love Composition API...
Anyways, .value is not a problem for me xD
Less magic is always better. And ts helps to know what is what.
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 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.
.value actually good so that we can differentiate the reactive variable or just a variable
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?
Hell of a lot more confusing with $ than just using .value
.value is needed in the javascript but you can mutate without .value in the template
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.
Why can't I use $ref in nuxt3 project?
Ty for video! Pls stop scroll up and down in 14:18 ))
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 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.
a mess with $'s
dollar sign frenzy
So reactive is just ref with extra steps?
Other way around. ref is a reactive that exposes a value property.
This feature has been dropped in version 3.4
Great video.. but $$ .. and toRef.. definitely its a mess
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
I still think this $ feature, will make who doesn't understand reactivity feel more confuse.
Remove .value simply confuse us whether it is reactive variable or not. No doubt code shorter
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.
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 will use it or not, but it was interesting. Thanks.
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!
I literally never use reactive
Options API: look at all the hoops they have to jump through just to mimic a fraction of our power!!!
It gets better
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."
Reactivity transform depreciated. Lmao
They will be removing this feature in 3.4
Yup, this is an older video!
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
Oh god. Keep things simple. :(
I will.
The feature has unfortunately been dropped.
Which one?
$ref@@ProgramWithErik
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.
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
Warning! Reactivity Transformed is being dropped by Vue in the coming months
Such an overenginnering just for nothing, lmao
$() $$() 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
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.