js developers make is defining data with reactive and then trying to destructure that react data. The issue here is that it's a little tricky to catch and doesn't immediately appear to be an issue. Because right now, I have a reactive object. It describes an animal.
The name is a lion. Is diet a carnivore? And the lifespan is eight to twelve years. Down inside the template, I have each of those items printed out along with a label that describes the data.
Over on the right-hand side of the page, everything does look correct. Lion displays next to name, carnivore next to diet, and lifespan is the correct eight to twelve years. What happens though when I try to change any of this data that describes the animal? Well, let's do that in the DevTools and find out.
So I'll change diet from carnivore to herbivore. Why not? Couldn't you imagine a lion eating carrots? Apparently my browser can't because it did not change.
The lion is still a carnivore. So what happened? I mean, I am using the reactive function, so my data should be reactive. Well, the issue is that you cannot, absolutely cannot, destructure the data from a reactive object.
Why? Because it's the object itself that it's reactive, not its individual properties. So as soon as you do the destructuring, the reactivity is lost. OK, well, what is the alternative then?
You have a couple of different ways you could go about this. I could import computed from view. And then, just to save time, I'll only do this for one of them, but then define it as a computed prop. I'll give the browser a refresh for good measure.
name here. We'll say lion goes to lion face. Okay, great. So that does actually reflect in the browser, even though we're using the short just name variable down here.
That's because of the computed prop. Now, for items that you only want to be read-only, that is, name can't be mutated to some other value directly. name. If you wanted this to be read-only, then the computed works great.
Your other option is to remove computed, remove the computed prop down here, comment out that, and then just use the actual reactive object down inside the template. diet, and so on and so forth. And that would work fine as well. However, it is a little bit more to type.
So one final option you have is to use the two refs function from the core view library. What we can do with two refs is, well, first I'll add name back in here and then we can call it on the reactive object that we want to structure. Now let's try things out in the dev tools one more time. So this time I'm going to change diet carnivore here under the animal reactive object.
We'll say carnivore two and sure enough, it updates on the page. We'll notice here that it also updated my diet ref, my diet reactive ref right down here. diet. diet right here updates as well, which I think is pretty cool.
Now some people might not ever come across this issue when they're just coding inside of a component, but one of the places this really comes into effect is when you're creating your composables. So here I have a use line composable created. I've got an animal object just like before defined with reactive, and then I'm returning animal. Well, back inside of my component, the way a lot of composables are expected to be used is via destructuring.
So I expect that I should be able to import useLion here. And then I would probably do something like const diet, lifespan, and name equals useLion. Now I can get rid of my manual implementation here inside of the component. Over in my browser, when I refresh the page, sure enough, everything continues to display.
But our reactivity is once again lost because we're doing the exact same thing now in the composable that we were doing badly over in the component. So what you want to do is make your composables able to be destructured. It's a pattern that many Vue devs already expect. And if you aren't making your composable destructurable, then it's not going to be intuitive to use.
So the solution is simple. It's the exact same thing we did over the component. We can import two refs from view and then call it on the returned object. Now you know how to prevent some pesky bugs when working with reactive and destructuring your data.