Don't quite understand reactivity

[joerattz]

I have some questions regarding Pinia and reactivity. I'm losing reactivity, possibly in multiple ways.

The docs here https://pinia.vuejs.org/core-concepts/#using-the-store say:

Once the store is instantiated, you can access any property defined in state, getters, and actions directly on the store.

I sure think it would be more helpful if that sentence continued with something like "but doing so will lose reactivity.", if that's correct.

Then farther down the same page it says:

In order to extract properties from the store while keeping its reactivity, you need to use storeToRefs().

That makes it sound like we shouldn't access properties directly on the store as the first referenced documentation suggests, unless I am misunderstanding what 'properties' are.

When that says 'properties' does that apply to state properties only (the properties on the state itself) or does it also include getters and actions? I'm losing reactivity on (some, if not all) my getters.

But here https://pinia.vuejs.org/core-concepts/getters.html they say:

Getters are exactly the equivalent of computed values for the state of a Store.

When I examine in devtools in my component's code, a getter is just an object but a local computed is a ComputedRefImpl. Is that an indication something is wrong with my getter thereby explaining why I'm losing reactivity? In the image below, dashboardDealStage is a local computed in the component and dealStore.getDashboardDeal is my getter (and it's returning an object, not a ComputedRefImpl).

After the documentation states this:

In order to extract properties from the store while keeping its reactivity, you need to use storeToRefs().

It demonstrates using storeToRefs to maintain reactivity. Doing this makes my getters reactive, meaning this works!

const { getDashboardDeal: dashboardDeal } = storeToRefs(dealStore);

But, that creates a ref. If getters are computeds, why should I need to create a ref for them? That doesn't make sense to me which makes me think I'm misunderstanding something and doing something wrong.

What am I missing? Thanks!

[kawazoe]

You are indeed misunderstanding some of the documentation here. You have to remember that under the hood of Pinia is just an object declared using the ref() function from vue; so all of the same restrictions applies.

The doc is really telling you that, just like any reactive object in vue, there are specific ways to access properties so that they remain reactive.

// This stays reactive: the proxy object (store) can tell the computed ref when to refresh.
const dashboardDealStage = computed(() => dashboardStore.dashboardDealStage);
const dashboardDealStage = computed(() => {
  const { dashboardDealStage } = dashboardStore;
  return dashboardDealStage;
});

// This stays reactive: the proxy object (store) can tell the view engine when to refresh.
<div>{{dashboardStore.dashboardDealStage}}</div>

// This looses reactivity: the value extracted is not a ref or a proxy and cannot inform the view engine of changes.
const dashboardDealStage = dashboardStore.dashboardDealStage;

All of this applies to any object created with reactive(), not just pinia.

What storeToRefs does is take all of the properties on the reactive object and make them available as collection of refs instead, while filtering out store specific functions.

// This stays reactive, even without computed because the resulting const is already a ref.
const dashboardDealStage = storeToRefs(dashboardStore).dashboardDealStage;
const { dashboardDealStage } = storeToRefs(dashboardStore);

The same rules applies for state values and getter values. Once you extract the value in a non observable manner, you loose reactivity. The only difference with getters is that they are re-computed automatically when the state of the store changes. They are implemented as computed values under the hood, but they are still exposed on the reactive object in an unwrapped form. Meaning, in the getter doc that you linked, the type of doubleCount is still number and not ComputedRef<number> because this is what happens if you try to put a computed value in a reactive object using the vue API alone.

const count = ref(42);
const doubleCount = computed(() => count.value * 2);
const reac = reactive({ doubleCount });

// count is type: Ref<number>
// doubleCount is type: ComputedRef<number>
// reac is type: UnwrapNestedRefs<{ doubleCount: ComputedRef<number> }> which expands to: { doubleCount: number }

[posva]

I think it's worth reading https://vuejs.org/guide/essentials/reactivity-fundamentals.html#limitations-of-reactive if you don't understand why storeToRefs() is needed or why it returns refs. Note the limitations of destructuring apply to ref()s as well

[zachbryant]

What I don't understand is that storeToRefs is even necessary at all. It makes me wonder why I'm not just defining a regular class with getters/functions but using ref instead of reactive. In what case would one ever want to use state.myGetter instead of the ref wrapper? When I first started reading the docs, it does lend itself to thinking state.myGetter is good enough, but I haven't yet come across a scenario where refs weren't necessary.

[kawazoe]

@zachbryant ref, reactive, and storeToRefs have very different uses and you don't have to use them if they don't suit your needs.

ref will wrap the value you give it. This means that every time you want to access it, you need to use .value. This can quickly bloat your codebase and might not be desirable. It's a simple solution to make things reactive, but it's also a verbose one.

reactive converts the object you give it into a proxy that embeds reactivity at the getter/setter level. This is very convenient since you do not need to add .value everywhere. You can keep using your types like if they weren't reactive. It's a more technical solution that some people might even call "magical".

Already, you can see that each have different drawbacks. If you only need a reactive number, you can either use ref, or wrap it in some object to use reactive. If you don't know what type you're going to make reactive in advance, you might want to use ref, since reactive won't work on basic types.

However, in both cases, you cannot destructure them without loosing reactivity.

With a ref, the moment you get the object out with the value property, you're no longer using a ref. It's obvious that the ref will not be aware of changes to the value at this point.

With a reactive proxy, it's the same issue, but a bit more subtle. Once you extract the value of a property from the proxy, you get a plain value, and not another ref or reactive proxy.

const aRef = ref({ foo: 42 });
const aReactive = reactive({ bar: 42 });

aRef.value = { foo: 43 }; //< vue is aware of this change and will render the template
aReactive.bar = 43 //< vue is aware of this change and will render the template

const { foo } = aRef.value;
const { bar } = aReactive;

foo = 44;  //< vue is NOT aware of this change and will NOT render the template
bar = 44;  //< vue is NOT aware of this change and will NOT render the template

This is important because destructuring is convenient and useful. It's something people want to be able to do, specially on large complex objects with tons of properties... like pinia stores. You do not have to do it, but if you want to, you can't because a pinia store is a reactive proxy object. Or rather, you can, but any change to the state behind your getters will not propagate in the template.

This is why storeToRefs exists. It takes all properties on a reactive object (like a store), and create a new plain object that will expose the same properties, but as their own little reactive "roots". This is a plain object, so it can be destructured safely. Each properties are now independent refs, so they remain reactive.

const aReactive = reactive({ foo: 42, bar: 42 });

const { foo } = aReactive;

foo = 43;  //< vue is NOT aware of this change and will NOT render the template

const { bar } = storeToRefs(aReactive);

bar.value = 43;  //< vue is aware of this change and will render the template

// It is equivalent to:
const refs = {
  foo: computed(() => aReactive.foo),
  bar: computed(() => aReactive.bar),
}

In the end, storeToRefs is just a tool to let you destructure a reactive object without loosing reactivity. Nothing more. You can still pass around your store and access your getters directly if you want. It's perfectly fine. However, remember that because your store is just a reactive object like the ones created by reactive, then you cannot destructure it and stay reactive. If you ever want to destructure your store, you need storeToRefs.

[macco3k]

This makes no sense whatsoever. If we define refs inside a store, e.g. via the setup api, why would we need to ask for refs again by calling storeToRefs? I'm not talking about destructuring, just about being able to use store.property as a ref, just like it was defined in the first place.

It looks to me as if pinia is trying to be unnecessarily smart, causing unneccesary confusion by doing so. At no point in the docs it is stated that accessing store properties will lose reactivity https://pinia.vuejs.org/core-concepts/. Imo It would at least be nice to update it so it's clear the only correct way to keep reactivity is storeToRefs.

[kevinramharak]

Pinia unwraps all the refs when creating a store, there is, unfortunately, no intention of providing an alternative where refs are not unwrapped.
See #2506

At no point in the docs it is stated that accessing store properties will lose reactivity

Its stated right here is it not: https://pinia.vuejs.org/core-concepts/#Destructuring-from-a-Store.
You only lose reactivity if restructuring, and therefore you need the storeToRefs helper when restructuring.
If you mean to say you lose the reactivity because the ref is being unwrapped, i'd say you don't lose any reactivity at all. It is just converted from a ref to a reactive property.