Declarative reffing

[tomhicks]

One thing that often bites us in prod is the perf profile of valtio where we end up using things in hot code paths.

The solution is often to ref deeply-nested objects and update them immutably. In one part of our codebase we have a thing to check some proxies to make sure certain things don't get stored without reffing:

if (process.env.FELT_ENV === "dev" || process.env.FELT_ENV === "staging") {
  // Alert us if an element is saved into state without removing the proxy on coordinates
  subscribe(elementsProxy, (ops) => {
    for (const [, ids] of ops) {
      for (const id of ids as string[]) {
        const element = getElement(id);
        if (!element) continue;

        const proxyVersion = getVersion(element.coordinates);
        if (proxyVersion !== undefined) {
          const errorMessage = `An element was stored with proxied coordinates, which causes performance problems.\nYou must use preventCoordsFromProxying before putting your element into state.\n\ntype: ${element.type}\nid: ${element.id}`;
          throw new Error(errorMessage);
        }
      }
    }
  });
}

The problem is that with the way valtio state it typically updated, we have to remember to ref things as they go into the proxy.

It would be really nice if there was some way to build this behaviour into the proxy, something like:

const store = proxy(initialState, {
  shouldRef(path) => path[1] === "coordinates"
})

or even:

const store = proxy(initialState, {
  beforeAdd(value, path) => path[1] === "coordinates" ? ref(value) : value
})

These are ideas straight off the top of my head so underdeveloped but I think this could be useful.

[dai-shi]

Am I interpreting this correctly that ref works fine, but it's hard for developers to remember what has to be refed. So, it's a DX issue, not theoretically fundamental issue.

[tomhicks]

Yes that's exactly right. Due to valtio's design, it leads developers to mutate proxies directly (as opposed to through wrapper functions like reducers) which leads to multiple places where updates can happen. That makes it hard to ensure all places that should ref an entry do so.

[dai-shi]

Currently, our strategy is to allow people to customize the internal behavior with unstable_buildProxyFunction.
Your suggestion can be implemented with it. If that seems valuable, let's create a new library.
There's a big hesitation to add features to the core. Basically, our API design is to avoid any "options" / customization.
That said, I believe unstable_buildProxyFunction is too low level. I think there's room for improvement so that it makes it easy to add this kind of new features.

[tomhicks]

yeah, makes sense. I wasn't aware of buildProxyFunction but it's something we've considered doing our own wrapper around proxy for various reasons but have held off.

[dai-shi]

Let me know how it goes. I'm happy to re-design the internal function.

[dai-shi]

backlink: #915 (comment)