Prefer object getters to derive util (changing our recommendation)

[dai-shi]

This is a huge idea, because I have been preferring and recommending derive for computed properties for most cases.

Recently, we updated docs with #647 by @stephenh and #732 by @alexander-entin.
It turns out that object getters work pretty well if we use it carefully.
We have some open issues with derive #685 and #687 and I'm currently not very confident with its implementation. We could try fixing it or even re-implementing it.
On the other hand, having two ways for computed properties is confusing and worse in DX.

So, I would like to recommend using object getters instead of derive.
The derive util will be maintained in a separate package, and will be removed from Valtio v2 #703.

There are a few issues:

• Migration isn't one-to-one, so we don't know if we can cover all usages in advance.
• There are some unsupported patterns like non-sibling access. 👉 subscribe or watch for workarounds

What we need to do is to collect derive usage and see if it's possible to migrate to object getters.

[dai-shi]

If we do this, I would move the current implementation to a third-party package: https://www.npmjs.com/package/derive-valtio

[DavidMulder0]

Am I misunderstanding the proposed alternative, or will object getters get executed every single time they are accessed? My understanding was that the point of computed state was that it updates and gets computed when its dependencies change, because otherwise you could just use any old helper function in your render logic to work with your store.

[dai-shi]

Object getters are executed on every access, but snapshot will be cached.
derive is suboptimal in a sense that it's not optimized for property access. some people get confused with it.

const p = proxy({ a: 1, b: 2 })
const d = derive({ c: (get) => get(p).a * 2 })
p.b++ // will trigger re-evaluation of `d` even though it's unnecessary

For getters, we recommend using proxy-memoize to overcome it if required.

valtio/docs/guides/computed-properties.mdx

Line 170 in 13b4093

## State usage tracking with `proxy-memoize`

[dai-shi]

If we were to keep derive in v2, we would probably re-implement it to be more simplified/maintainable/predictable with limitations, like giving up glitch-free.

[dai-shi]

Hi someone, I really need to understand some use cases that only work with derive. Can anybody share ideas that seem difficult with object getters?

From the library maintenance perspective, the major version up is the only way to drop a feature.
So, we should probably remove it first in v2 and then get feedback. We can put it back with a minor bump.

[dalcib]

I'm in favor of depreciating Derive, replacing it with Getters.
It will make Valtio closer to the standard JavaScript.
The only situation where I remember that can be impacted with it is that Getters can reference sibling props only. The docs recommend to use derive instead.

[dai-shi]

Thanks. Yeah, it's not one-to-one.

I think we should first update docs and then add migration note.

[dai-shi]

#798

[dai-shi]

After merging #798, I will move the derive util to another repo, and make it a dependency.
I hope to maintain it but it depends on users and contributors.
My current plan is to remove the dependency in v2 but keep it in docs.

[dai-shi]

#802

[dai-shi]

#798