The right way to set up computed/derived data in the store

[ivan416]

Hello,

I need some opinions on what would be the best way to set up computed/derived data in valtio store.

1. Store a function inside valtio

const state = proxy({
  count: 1,
  doubled: () => state.count * 2
})

2. Use addComputed

import { addComputed } from 'valtio/utils'

const state = proxy({
  count: 1,
})

// add computed to state
addComputed(state, {
  doubled: snap => snap.count * 2,
})

Are there any issues using approach in the first approach? For the record I'm using React and the following part in the documentation left me confused.

Dependency tracking in valtio conflicts with the work in useSnapshot. React users should consider using render functions (optionally useMemo) as a primary mean. Computed works well for some edge cases and for vanilla-js users.

Thank you in advance and thank you @dai-shi for this simple and clean state library!

[dai-shi]

Thanks for opening this up. There are pros/cons, and can't recommend "one" way.

state function to get state (computed) value

const state = proxy({
  count: 1,
  doubled: () => state.count * 2
})

This code alone is valid and state.dobuled() works just fine.
However, there's a pitfall when using with useSnapshot:

const Component = () => {
  const { doubled } = useSnapshot(state)
  return <div>{doubled()}</div>
}

This is not reactive because doubled is reading a mutable state object. So, even if count changes, this component won't re-render.

state function with this that works with snapshot

To do it correctly, here's the solution.

const state = proxy({
  count: 1,
  doubled() { return this.count * 2 }
})

const Component = () => {
  const { doubled } = useSnapshot(state)
  return <div>{doubled()}</div>
}

This works. It's reactive to count, because doubled reads from this which is a snapshot.

custom hooks

However, using this can be confusing, so I guess that's for experienced users.
I would recommend custom hooks instead for beginners.

const state = proxy({
  count: 1,
})

const useDoubled = () => {
  const snap = useSnapshot(state)
  return snap.count * 2
}

const Component = () => {
  const doubled = useDoubled()
  return <div>{doubled}</div>
}

custom hooks with useMemo

If the computation is heavy, we can use useMemo.

const useDoubled = () => {
  const { count } = useSnapshot(state)
  return useMemo(() => count * 2, [count])
}

Note that it's highly recommended to pass primitive values to useMemo deps.

However, this memoization works only for each component.

addComputed/proxyWithComputed

If you want the computation to happen only once the state value changes, computed helps.
If the computation is really heavy, this will improve performance.
However, if you overuse it, it will decrease the performance.
So, unless you plan to measure performance, I wouldn't recommend using computed.
(On the other hand, if you don't care about such overhead, and would consider computed is good only for encapsulation, it's fine.)

My gut feeling is in most use cases such computation is not so heavy (if it's heavy, I'd consider off-load main thread = web worker, works only on browsers or so), and using computed is slower than custom hooks solutions. (the exception is if the not-so-heavy computation is in many components, but then we should measure for such use cases.)

---

So, it depends. Which one seems to fit with your use case?

[dai-shi]

That doesn't work as you may expect as doubled is only evaluated once at the creation time. Do you mean like this?

const state = proxy({
  count: 1,
  doubled() { return calculateDouble(this.count) }
})

const calculateDouble = (num) => num * 2;

or this

const state = proxy({
  count: 1,
  doubled: calculateDouble,
})

const calculateDouble = function() { return this.count * 2 };

[ivan416]

Yes, thank you for providing the examples. Would useSnapshot have any issues? I'm assuming no since doubled would still be reactive to count.

[dai-shi]

Those two work fine with useSnapshot because this refers to a snapshot.

[ivan416]

Great! Really appreciated all your comments!

[GorvGoyl]

coming here to comment that functions are not the best way to do this. Below code will not show TS error even though doubled is used in if condition instead of doubled()

const Component = () => {
    const { doubled } = useSnapshot(state);
    if (doubled) {
        return <div>{doubled()}</div>;
    } else {
        return null;
    }
};

I guess the new recommended way is this: https://github.com/pmndrs/valtio/blob/main/docs/guides/computed-properties.mdx

[ndrean]

I might be doing something wrong but I don't find out where I did it when I used the custom hook proposed to be a solution (see below): I still get the linting error "better to just use proxy state".
Perhaps the linter may have changed since June 2021 when this post has been written?

const useDoubled = () => {
  const snap = useSnapshot(state)
  return snap.count * 2
                ^^^^ Better to just use proxy state.eslint(valtio/state-snapshot-rule)
}

When you don't want to modify the state but just render a modified state, then the linter is happy and the component is reactive when you modify the snap directly in the return. But this usage may be somehow of little interest.

const doubled = c => c*2
const Component = () => {
  const {count} = useSnapshot(store)
  return <p>{doubled(count)}</p>
}

Any comment/update?

If I want to modify the state within a component, then a callback acting on the state and triggered by a button will render. But this is also a limited use case

const store = proxy({
   count: 0,
  double: ()=> store.count *= 2
})

const Component = () => {
  const snap = useSnapshot(store)
  const action = ()=> store.double()
  return( <>
           <button onClick={action}>double</button>
            {snap.count}
         </>)
}

[dai-shi]

Oh no, that looks bad...

[dai-shi]

Can you file an issue in https://github.com/pmndrs/eslint-plugin-valtio?

[ndrean]

Yes if you explain why my last one is bad :)

[dai-shi]

oops sorry for misleading.
that looks bad because the lint warns, while the code is good.

[barelyhuman]

i think the read separation fix was added in one of the recent PRs, i’ll go through this again but.

yes, this isn’t wrong unless you actually try to modify the snapshot, just reading from it should not cause any issues during rendering.