Is legal returning implicitly readonly state?

[giolf]

Based on this sentence in the Pinia documentation:

Note that you must return all state properties in setup stores for Pinia to pick them up as state. In other words, you cannot have private state properties in stores. Not returning all state properties or making them readonly will break SSR, devtools, and other plugins.

Am I asking to myself if something like this is ok

export const useCounterStore = defineStore('counter', () => {
  const count = ref(0)
 
  function increment() {
    count.value++
  }

  return { count: readonly(count), increment }
})

Basically the original count is not readonly, and it can be updated by the increment function.
However it is returned implicitly by a Proxy through the object count property.

Is this approach violating the rule mentioned previously? 👇🏼

Not returning all state properties or making them readonly will break SSR, devtools, and other plugins.

Or is totally fine doing it in this way?

Thanks in advance.

[posva]

It's not allowed (it's explicitly mentioned in the docs you quote). The only fully safe way of having private (or readonly state) is by moving it into another store that returns a regular writable state

[giolf]

Thank you for you answer.

So If I understood correctly, doing this Is perfectly fine right?

// we don't expose this store but it still picked up by pinia
const usePrivateState = defineStore('store-private', () => {
  const secret = ref('Never seen outside')

  return { secret }
})

export const useStore = defineStore('store', () => {
  // we can just use the store here
  const privateState = usePrivateState()

  return { secret: readonly(privateState.secret) }
})

Thanks

[posva]

It should be but it's better if you use a computed instead of readonly because it gets recognized as a getter instead.

[giolf]

the problem to use a computed instead of readonly (when working with objects) is that you can change the value by reference:
computed.value.objectProp = 'value changed' since the computed just prevents to change the value its holding (the reference). With primitive values (such the secret in the example, I agree with you).

But with readonly I can prevent to change any nested level of an object.

Any suggestions? Maybe:

return { user: computed(() => readonly(privateState.object)) }

Thanks

[posva]

both should work. Maybe I could treat readonly as getters two. I will note that down

[giolf]

both should work. Maybe I could treat readonly as getters two. I will note that down

That would be great. I think it should be a quick update for the next release right?

Thanks