Ideas for v3

[dai-shi]

Just some notes for myself. Nothing is determined.

• Wait for use(store) https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more#concurrent-stores and redesign our API
• O(1) useSnapshot O(1) time complexity subscribeKey and useSnapshot for big N keys proxy #1161
  • drop proxy-compare
  • introduce applyChanges() like https://github.com/jotaijs/jotai-valtio
• Always notifyInSync=true and introduces batch() like https://github.com/valtiojs/valtio-reactive
• Drop watch with deprecating it in v2
• Replace unstable_replaceInternalFunction with more robust/pluggable solution.
• React Native: "ownKeys target is non-extensible but key is missing from trap result" when calling Object.entries #874 (reply in thread)

[pooya-badiee]

Hi. Thank you for your great work
wanted check why some of the utilities is separated into valtio-reactive.
from our teams POV it conveys more confidence to be able to import it directly from valito, specially the computed utility

[dai-shi]

Many utilities are separated into ecosystem packages because:

• Not all users need them
• It's easier to add collaborators
• It can be developed with more speed.

From my point of view, I will be more confident if there is more feedback on valtio-reactive. I was looking for some collaborators, but didn't find any so far. I'll try it again.

[pooya-badiee]

@dai-shi thank you for your response. I respect your design choice.
hopefully I'll be more familiar with Valito and be able to contribute back

[imrnck]

Hey, thanks for the great work on this library!

I noticed that you mentioned planning to enable notifyInSync: true by default in v3. Could please you share a bit more about the motivation behind that decision?

I’m currently building a higher-level state management solution on top of Valtio, and I’m trying to understand how this change might affect my implementation going forward.

Right now, I’m working on a “selectors” concept for the store. The idea is that selector subscribers are only notified when the specific properties they access actually change. This is implemented using effect from valtio-reactive.

Here’s a simple example of a selector:

filteredItems(key) {
  return this.state.items[key] + this.state.counter
}

And subscribing to it:

store.filteredItems.subscribe("key_1", value => {
  // ...
})

Under the hood, the selector implementation looks roughly like this:

subscribeSelector: (callback) => {
  const proxyObj = proxy({ value: undefined });

  const effectUnsubscribe = effect(() => {
    proxyObj.value = selectorFn(...args);
  });

  const subscribeUnsubscribe = subscribe(
    proxyObj,
    () => {
      callback(snapshot(proxyObj).value);
    },
    true,
  );

  return () => {
    effectUnsubscribe();
    subscribeUnsubscribe();
  };
},

When notifyInSync: true is enabled in subscribe call, everything that runs inside the subscription callback ends up executing within the effect context. In my case, this can lead to unpredictable behavior and, in some situations, infinite loops.

To solve this, I switched to subscribing asynchronously so that updates happen in a separate event loop, which resolved the issue.

Given that notifyInSync: true will be the default in v3, do you think this change could impact patterns like this? I’d love to hear your thoughts on the recommended approach.

[dai-shi]

Could please you share a bit more about the motivation behind that decision?

Originally, we needed to batch for React, but newer React handles it well without it.
We want our api surface smaller, and adding the batching behavior is possible in userland.

This is implemented using effect from valtio-reactive.

effect uses notifyInSync: true anyways.

https://github.com/valtiojs/valtio-reactive/blob/39153c355aafe3a5b6fb3e5c07d474312e27c490/src/core.ts#L102

do you think this change could impact patterns like this?

So, if you are using valtio-reactive and not subscribe from Valtio, there's nothing to change.

[ScreamZ]

My turn for suggestions :

About notifyInSync

Currently in I'm using valtio in react and server side, and i love the auto-batching feature of notifyInSync = false on server side. I know valtio was originally designed for react, but I might be one of the few using it in server side for manage reactive state of Gaming rooms (i made something like the colyseus framework).

As far as i understand, without valtio-reactive i couldn't have the same behavior ? Could we consider changing the default but keep the possibility ?

Add branded types

Currently it's hard at development time to guess whether an object is a proxy or not.

I vote for a Type branding for proxy useSnapshot and all derivated stuff that consume proxy.

You can grab more at https://github.com/sindresorhus/type-fest/blob/main/source/tagged.d.ts

Tagged - Create a tagged type that can support sindresorhus/type-fest#665 and per-tag metadata. (This replaces the previous Opaque type, which is now deprecated.)

I'm already wrapping valtio stuff like this in my code, and this add more security layer.

[dai-shi]

Ah, my bad. I got confused. ref is branded, not snapshot.
But, on second thought, I think branded types for proxy will cause issues for many use cases. snapshot is probably fine, because it's readonly.
So, my take for now is that branded type shouldn't be the default. It can be an opt-in feature though.
I don't love depending on another package, so maybe a separate library would be nice. If you are interested in it, you can lead the project. Otherwise, I'll try when I have a chance or maybe @overthemike might be interested in it.

[ScreamZ]

I think after subscribe forcing notifyInSync=true, we could create a util subscribeInAsync

Sounds goods

I'm not sure what you mean. Does valtio-reactive solve your issue currently?

I'm not using it right now, but after re-reading the documentation, It looks like I could drop all subscribe and subscribeKey statement for effects

The only issue (which can be mitigated with some wrapping and handling a boolean on my side, or with a new parameter/variant) is that I don't want the effect to runs the first function (fn) immediately.

I'm just not sure why we keep both valtio-reactive and valtio primitives like subsribe and subscribeKey we already disposed things like watch but having too many options make it harder for adoption and reason about.
Maybe i'm missing something

Snapshot types are branded. We could do the same for proxies. We don't need to wait for v3. Would you like to send a PR?
But, on second thought, I think branded types for proxy will cause issues for many use cases. snapshot is probably fine, because it's readonly.

Good new for snapshot, but for proxies, currently it can be easily confused with a POJO, but has side effects, and hard to debug in such case. A simple proxy.array.sort call (instead of .toSorted) can trigger modification.

For react as most of the time things are managed using useSnapshot, this is less likely to happen but in others contexts... Especially when you pass the proxy as arguments to functions, or many function, it can be forgotten quickly its a proxy.

I'm sure there are some problems in some edge case doing branded proxy, but I'm thinking how we can mitigate the risk of editing a proxy while thinking it was not.

You can copy/paste the branded type from type-fest its pretty small, I'm not sure making another package would be useful (and add some complexity to the valtio ecosystem) but I understand your concern

[dai-shi]

We love small core and having ecosystem libs outside it. When it gets well tested or widely adopted, we my consider extending core (but still preferring minimal).

That's how valtio-reactive is designed. It's not required for some use cases, but it might be useful for others. If it gets popular, we could move to the core, but it feels not yet. v3 will take part of the idea, like batch, but not sure about effect as the semantics is different and it has an overhead (less performant theoretically).

Same applies to branded types. Instead of adding it to the core immediately, we play with the idea in an ecosystem lib. We hope to get feedback. Eventually, we may keep it as a lib and promote the usage, or may consider adding it to the core. We are conservative about changing the core, but love to experiment with ecosystem libs. ( @overthemike 's https://github.com/valtiojs/valtio-plugin is a good example.)

Maybe what's missing is to increase the presence of https://github.com/valtiojs, and educate users to seriously try and use ecosystem libs.

[ScreamZ]

We love small core and having ecosystem libs outside it. When it gets well tested or widely adopted, we my consider extending core (but still preferring minimal).

I love it too, my point is to make it even smaller, and specify good references on existing augmentations. As valtio-effect is mostly doing the same thing as subscribe very soon.

Same applies to branded types.

For sure. (as would says my French president)

Maybe what's missing is to increase the presence of @valtiojs, and educate users to seriously try and use ecosystem libs.

Sure thing I wasn't even aware of the existence of this repository at start.

Not to make critics, I don't want to be that guy, but a rewrite of the doc using https://www.mintlify.com/ or something like that could be nice and gives a french baseline for v3. There are good frameworks for that right now, such as docusaurus, vue-press, or my fav mintlify (free for oss)

Or at least mention more about existing things, like ecosystem libs, example use cases. Core api not documented

https://valtio.dev/docs/api/advanced/subscribe don't even mention the notifyInSync parameter, people have to refer to types checks.

These slow the adoption for sure, as the lib is really strong and game changer for many scenario.

[dai-shi]

Currently, I don't think anybody is actively maintaining our docs. Without contributors, we can't move forward. My only requirement is that ./docs should be browsable in github.

It might be a good idea to show the featured ecosystem libraries in our docs and website. (Jotai website does it somewhat.)