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.

[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