The ValtioProxy Superclass Pattern (and its limitations)

[pastelmind]

I discovered a useful pattern for class-based state, using a trick called return overriding:

class ValtioProxy {
  constructor() {
    // This uses a technique called "return overriding"
    // A child class that inherits this will interact with the proxy object
    // instead of the original object
    return proxy(this)
  }
}

// Person inherits from ValtioProxy
class Person extends ValtioProxy {
  // Class fields are added directly to the proxy object
  name = 'Mary'
  age = 50

  constructor() {
    super()

    // These are also added directly to the proxy object
    this.weight = 90
    this.birthday = new Date(/* ... */)

    // Foo receives a proxy, even in the constructor
    this.someObject = new Foo(this)
  }
}

Benefits

Simply Reactive

Any class that inherits ValtioProxy is reactive by default:

// person is already a proxy object; no need to wrap it with proxy()
const person = new Person()
// Can create snapshot immediately
const snap = snapshot(person)
// This will notify listeners and re-render views
person.age = 20

Eliminates this confusion

In ordinary classes, the this keyword is tricky because sometimes it is a proxy, but sometimes it is not.

class Person {
  name = 'John'
  // 'this' is a plain Person instance here
  pet = new Pet('Fido', this)

  constructor() {
    // 'this' is a plain Person instance as well
    doSomething(this)
  }
}

This can be problematic when you want to exclude some classes from the proxy state tree with ref(), but still let them access other state:

class Person {
  name = 'John'

  // Using ref() to make 'pet' non-reactive.
  // Pet constructor receives a plain Person instance,
  // not a proxy object!
  pet = ref(new Pet('Fido', this))
}

class Pet {
  constructor(public name: string, public owner: Person) {}
  // This reads from the original Person instance
  getOwnerName() { return this.owner.name }
}

// proxy() creates a copy of the Person instance,
// which is decoupled from the original Person object
const person = proxy(new Person())

person.name = 'Mary' // Updates the proxy but NOT the original
console.log(person.pet.getOwnerName()) // 'John' 😨

Passing proxy(this) to new Pet() does not solve the problem. (click to see why)

Suppose we pass proxy(this) to the Pet constructor:

class Person {
  name = 'John'
  pet = ref(new Pet('Fido', proxy(this))) // Hope this works 🤞
  age = 50
}

// ...

const person = proxy(new Person())
console.log(person.age) // 'undefined' 😨

What happened? When we invoked proxy(new Person()), the following happens:

1. Person is constructed.
   1. Field name is initialized on the Person instance.
   2. Field pet is initialized on the Person instance.
      1. proxy(this) is invoked. It created a new proxy by copying all properties on this to a new object. Notice that the age field is not initialized yet.
      2. A Pet is instantiated.
   3. Field age is initialized on the Person instance.
2. proxy() receives the created Person instance. Since it is the same instance passed in the proxy(this) call, it returned the cached proxy object (which is missing age).
3. Oops, now we have a person with no age.

This can be avoided by moving pet to the bottom of the class body:

class Person {
  name = 'John'
  age = 50
  pet = ref(new Pet('Fido', proxy(this)))
}

const person = proxy(new Person())
console.log(person.age) // '50'
console.log(person.pet) // 'undefined' 🤔

But it still does not fix the problem: person.pet is missing, because it was not on this when it was initialized. It's a chicken-and-egg problem.

This can be solved by using ValtioProxy:

class Person extends ValtioProxy {
  name = 'John'
  // 'this' is a proxy object from the get-go
  pet = ref(new Pet('Fido', this))
  age = 50

  // ...
}

// No need to call proxy()
const person = new Person()
person.name = 'Mary'
console.log(person.pet.getOwnerName()) // 'Mary'
console.log(person.age) // '50'

Limitations

When using ES2022 class fields, objects and arrays are not made reactive:

class Person extends ValtioProxy {
  cars: Car[] = [] // ❌ Not reactive
  // ...
}

const person = new Person()
// Will not notify listeners or re-render views
person.cars.push(new Car())

This is because ES2022 class fields use Object.defineProperty() semantics, and therefore do not invoke the set trap of Valtio's proxy object.

One workaround is to initialize objects and arrays in the constructor:

class Person extends ValtioProxy {
  cars: Car[];

  constructor() {
    super()
    this.cars = [] // ✅ Reactive
  }
}

It would be nice if we don't have to care about this, though.

Feature suggestion: Support ES2022 class field initialization

Would it be possible to support class fields as reactive properties, even when they are objects or arrays? Yes, if we add a defineProperty trap to Valtio's proxy that invokes our listeners.

Intercepting all possible defineProperty calls is too big a task. For now, we can focus on true class fields, which are always CEW (configurable, enumerable, and writable). We could limit the trap to creating CEW own properties, and only if (1) either the property does not exist, or (2) if an own property exists and is also CEW.

I have submitted a pull request for this. (#760) Feedback is welcome!

[uoon-dev]

cool solution 👍

[dai-shi]

Let's merge #760.