Allow not unwrapping refs when using store

[coolCucumber-cat]

What problem is this solving

So when you use a store, it wraps it in a reactive, which is helpful since you don't have to use .value and it means composition and options stores are the same. But it's also really annoying because it's not what you expect it to be if you're returning refs and you can't destructure them. It's quite annoying to have to use storeToRefs or computed when it's not really necessary.

Proposed solution

Solution 1: Allow passing an options object when you create the store, including the two current options, plus an option to not unwrap refs. This would be harder because wrapping it is done when you define it, at least that's what it looks like when I look at the source code.

Solution 2: Make this an option when you define the store instead of when you create it. This is easier, but it's probably not as good since it isn't obvious when you use it, you'd have to look at the definition or maybe the types.

Describe alternatives you've considered

No response

[posva]

For now, there is no intention of shipping this feature with the existing ones because it makes things different when using the store, while it is not explicit why things are not unwrapped anymore (still same useStore() call). In practice, I've played with both ideas, and I rarely extract refs from the store, I use the store directly, as a whole, as a service. You don't need to use storeToRefs().
It's also worth noting that this can be implemented in user land with a custom defineStore that calls storeToRefs().

That being said, I don't want to give up the idea yet completely, so I will move it to Discussions and see if the community comes up with other arguments

[coolCucumber-cat]

What about readonly refs? If you return a readonly ref or just declare it as readonly, it doesn't do anything because it gets unwrapped. Currently the only way is a computed ref which is kinda annoying. 5 of the 6 different values I return from 3 different stores are all readonly and only supposed to be mutated through functions in the store. For example, you shouldn't be able to change isLoggedIn or currentUser, you should have to call login and logout.

[posva]

Returning readonly refs break some features: #2402 (reply in thread)
Although I don't think that's related to the original idea.
But as said, I'm not giving up on this idea. I need to take time to inspect even more projects' usage of pinia. I agree sometimes it's useful to just extract the couple of properties we use, it's just far from being always the case in my experience.

[JosXa]

I need to take time to inspect even more projects' usage of pinia.

I presume that most users (me included) work around the concepts that Pinia prescribes. Where you would ordinarily (want to) use refs, you accomodate Pinia's philosophy and change your code to fit, even when you know it's not optimal.

So you might not find many projects that attempt to hack the library just to match the intended approach :)

[NikhilVerma]

I have a similar issue, I have a store where I want to keep a document with thousands of lines. I would prefer to keep it is as a shallowRef instead of shallowReactive because with shallowRef you can easily tell via Typescript that something needs to be mutated, with shallowReactive it's a bit of a black magic that you need to be aware of.

However Pinia just urefs all my references. My solution so far has been to return a computed prop which returns a global module refer shallowRef. However this breaks typescript types so it's not a great solution.

Would be great to have a utility like markRaw in Vue (e.g. noUnref) which will ensure that Pinia doesn't unref by default

[LZQCN]

Pinia wraps the composing-store in a reactive, which causes all ComputedRef deconstructed from the store to lose reactivity.
I wrote the following code, but it lost reactivity, which is very counterintuitive. 😩

const { allRolesComputedRef } = useRolesStore() // It has become a plain array, losing its reactivity.

[posva]

Prefer const store = useRolesStore() and store.allRoles. Use storeToRefs() or toRef() when you need to pass a piece of the store as a reactive property to another composable

[jotolo]

This problem could be solved by using a composable liked mentioned here before:

import { useYourStore } from '../stores/your-store';
import { storeToRefs } from 'pinia';

const useRefStore = () => {
  const store = useYourStore();
  const refs = storeToRefs(store);

  return {
    ...store,
    ...refs
  };
};

const { refA, computedRef, actionA } = useRefStore();

You can even go further and pass the store as a parameter and you will end up with a similar pattern to withDefaults(defineProps<T>()) pattern we have for props in Vue Composition API.
Maybe we can provide something like this in Pinia.

Another option would be to return actions in storeToRefs:

The docs says:

storeToRefs: Creates an object of references with all the state, getters, and plugin-added state properties of the store. Similar to toRefs() but specifically designed for Pinia stores so methods and non reactive properties are completely ignored.

Given that it is already there doing most of what we need, we are just missing the actions/methods defined in the store. Maybe that one could be the helper we are looking for? Maybe it is not possible.

[jotolo]

I will provide an example code. Please, keep in mind I don't want to carry the store around to execute my logic. I want to decompose everything as we do with, for instance, vue-use. I think this is the main problem here. If I want to use refs to properties from the store and actions decomposed I will need to do something like this:

const myStore = useMyStore();
{ refA, refB, refC } = storeToRefs(myStore)
const { methodA, methodB, methodC} = store

Notice how I need to do this in order to fully decompose the store in a reactive way. This is not ideal and it could be replaced with:

const myStore = useMyStore();
{ refA, refB, refC, methodA, methodB, methodC } = storeToRefs(myStore)

In my opinion this is way better than the example before. At least from the usage point of view.