Is there any penalty using reactive() rather than ref()?

I tend to use reactive() a lot more than ref(), so I don't need to remember the .value and I can organize related variables within a reactive object.

I was just wondering if that's an ok practice, or does that incur some sort of performance penalty or any other problems.

Thanks for any thoughts.

LaryAI

2 years ago

Level 58

In Vue 3, both reactive() and ref() are core functions that enable reactivity in components. The choice between using reactive() and ref() often comes down to personal preference and the specific use case. Here's a breakdown of the considerations:

reactive() is used to make an object reactive. It is useful when you want to group related data properties together. When you destructure a reactive object, you lose reactivity, so you should access properties directly from the reactive object or use toRefs() to maintain reactivity after destructuring.
ref() is used for primitive values like strings, numbers, and booleans, but it can also hold objects. It provides a reactive reference to the value it holds, which is accessed and mutated via the .value property. This can be a bit cumbersome when dealing with multiple refs, as you have to remember to use .value.

In terms of performance, there is no significant penalty for using one over the other. Vue's reactivity system is optimized to handle both cases efficiently. However, there are some subtle differences in behavior that you should be aware of:

reactive() provides deep reactivity, which means all nested properties become reactive. This is not the case with ref() when it holds an object; only the top-level property is reactive unless you explicitly make the object reactive before assigning it to the ref.
ref() is more versatile in that it can be used inside reactive() objects to provide reactivity for specific properties that may change independently.

Here's a simple example of using both reactive() and ref():

import { reactive, ref } from 'vue';

export default {
  setup() {
    const state = reactive({
      user: {
        name: 'Alice',
        age: 30
      },
      count: ref(0)
    });

    function increment() {
      state.count.value++;
    }

    return {
      state,
      increment
    };
  }
};

In this example, state.user is a reactive object, and state.count is a reactive reference. The increment function demonstrates how to update the count value.

In conclusion, using reactive() over ref() is perfectly okay if it suits your coding style and the structure of your data. There is no inherent performance penalty, but you should choose the one that makes your code more readable and maintainable for your particular situation.

gych

2 years ago

Level 29

Reactive is only for objects while ref can also be used for objects, strings, integers, etc.. I mostly use ref, its easy getting used to adding .value to access its value in script.

Max100

2 years ago

Level 6

Thanks for your reply! I still have a lot to learn about Vue, but at least I now know there's no major issue using reactive(). It definitely seems more like a question of style/preference.

But even though Lary explained things pretty well, I found the example a bit confusing. There's no need to make count a ref, because it's already in a reactive object. I know it's just done for demonstration purposes, but it seems to overcomplicate things.

In its simple form, I'd just do:

 const user = reactive({
       name: 'Alice',
       age: 30,
       count: 0,
    });

Then there's 3 reactive variables: user.name, user.age and user.count. Just modify each as needed.

user.name = 'Sally';
user.age = 35;
user.count++;

I'm sure there's more nuance involved, and I don't have a clue when I'd want deep vs shallow reactivity, so there's still much to learn.

Thanks again for your reply!

gych

2 years ago

Level 29

@Max100 In the background ref calls reactive so its perfectly fine to use reactive but because reactive only takes objects I prefer to use ref most of the time but that's more personal preference and depending on the use case.

For example, if I only need 1 reactive variable like: toggleNavbar, it would be weird to use reactive() for this and add this to an object. Using a simple ref is more straight forward in this case.

Using shallow ref/reactive can improve the performance for example when using larger objects. But it will also limit the deeper reactivity., with shallow reactivity you can only update the top level properties so not properties of nested objects.

For shallowRef this will be the value and for shallowReactive the first properties on the highest level in the object.

Example: ref() vs shallowRef()

const testRef = ref({
	user: {
	    name: 'Alice',
        age: 30
	}
})

const testShallowRef = ref({
	user: {
	    name: 'Alice',
        age: 30
	}
})

testRef.value.user.name = 'John' // This will trigger a change
testShallowRef.value.user.name = 'John' // This will NOT trigger a change
testShallowRef.value = {
	user: {
	    name: 'John',
        age: 31
	}  // This will trigger a change because value got updated and not the nested property.

Example: reactive() vs shallowReactive()

const testReactive = reactive({
	user: {
	    name: 'Alice',
        age: 30
	}
})

const testShallowReactive = shallowReactive({
	user: {
	    name: 'Alice',
        age: 30
	}
})

testReactive.user.name = 'John' // This will trigger a change
testShallowReactive.user.name = 'John' // This will NOT trigger a change because its a property of the nested object.
testShallowReactive.user = {
	    name: 'John',
        age: 31
	}  // This will trigger a change because the property on the highest level in this object is updated

I hope you'll understand my explanation, its not that easy to explain this but if you have more questions let me know and I'll do my best to make it more clear.

Max100

2 years ago

Level 6

@gych That clears things up and makes sense. Also, thanks for your explanation of deep and shallow reactivity, that'll be helpful when I run into those issues down the road. Thanks again!

1 like

gych

2 years ago

Level 29

@Max100 No problem, I'm glad I could help :) If you have more questions don't hesitate to reach out. If this answered your question don't forget to close the thread by selecting the best answer.

Please or to participate in this conversation.