Derived values in stores

[bisubus]

I'm moving pinia stores that are basically thin wrappers around vue reactivity api to valtio:

const useOneTwoThree = defineStore('oneTwoThree', {
  state: () => ({
    counter1And2: {
      counter1: 0,
      counter2: 0,
    },
    counter3: 0,
  }),
})

const useFourStore = defineStore('four', {
  state: () => ({
    counter4: 0,
    oneTwoThree: useOneTwoThree()
  }),
  getters: {
    sum: (state) => {
      const oneTwoThree = state.oneTwoThree
      // const oneTwoThree = useOneTwoThree() // can be moved here to avoid circular dep, if any
      return oneTwoThree.counter1And2.counter1 + oneTwoThree.counter1And2.counter2 + state.counter4
    },
  },
})

From what I see, it would be rewritten as:

const oneTwoThree = proxy({
  counter1And2: {
    counter1: 0,
    counter2: 0,
  },
  counter3: 0,
})

const fourPartial = proxy({
  counter4: 0,
})

const four = derive(
  {
    sum: (get) =>
      get(oneTwoThree.counter1And2).counter1 +
      get(oneTwoThree.counter1And2).counter2 +
      get(fourPartial).counter4,
  },
  {
    proxy: fourPartial
  }
)

Currently derive() looks like a close relative to computeds/getters but it's low level. The problem I see is that when there's a need to refactor a oneTwoThreeFour store to oneTwoThree and four, this results in more code changes including the need to keep state and derived state in separate variables (four and fourPartial). While the extraction of useOneTwoThree in pinia was trivial (getters also can uniformly refer a store through this, both state and other getters)

The thing that concerns me is the necessity to explicitly use get() in derive. Since both proxies are valtio, it could be expected that they could be able to be aware of each other and be able to track changes.

Any suggestions how the situation could it be improved? I hope I could end up with some more high level api for the stores

[dai-shi]

I'm not sure the exact requirement, but have you looked / tried this? https://github.com/pmndrs/valtio/blob/main/docs/guides/computed-properties.mdx

[bisubus]

@dai-shi Thanks, I probably overlooked this kind of usage from the docs:

const user = proxy({
  name: 'John',
})
const greetings = proxy({
  user, // attach the `user` proxy object
  // OK - can reference user props via `this`
  get greetingEn() {
    return 'Hello ' + this.user.name
  },
})

So it appears that the state above could be written as:

const four = proxy({
  counter4: 0,
  oneTwoThree,
  get sum() {
      return this.oneTwoThree.counter1And2.counter1 + this.oneTwoThree.counter1And2.counter2 + this.counter4
  },
})

What's the use case for derive() then in a similar situation? Except that it provides fine control with underive

[dai-shi]

What's the use case for derive() then in a similar situation? Except that it provides fine control with underive

derive() is developed before we establish this pattern.
It might be still useful for some edge cases.
That said, we are moving to a new library https://github.com/valtiojs/valtio-reactive, and if it covers such use cases, derive() will be deprecated.

[bisubus]

Thank you, this is exactly what I needed. And it looks pretty much close to vue reactive api I might add. I I should check https://github.com/valtiojs repos more often