Reaction (watch without getter)

[benjamind]

I've been trying to add valtio to my workflow within lit web components in a similar manner to my usage of mobx with the lit-mobx library. i.e. transparently without the need to manually subscribe, or use the watch get function.

For mobx this was achieved using their Reaction pattern, which allows us to have a data tracking function (in this case the lit update lifecycle method which is invoked just before render and is used to track the variables to respond to, and then an effect method which we use to request an update to the components. This split between tracking / effect allows for a more fine grained control of behavior.

I've implemented this by refactoring the watch method a little bit, and adding a basic automatic tracking of accessed proxies via the proxy get implementation. This seems to work pretty well, allowing for a very natural usage of properties without having to wrap each proxy access in a get call as we do with watch today. This makes adding observability via valtio to a lit element very natural since we can make it aware of observable properties through a mixin without having to rewrite the internal render functions.

As an example of usage within a valtio adapted lit element base class:

export class ExampleElement extends LitElement {
  @property({ attribute: false })
  public counter?: Counter;

  public render(): TemplateResult {
    return html` Count is ${this.counter ? this.counter.count : "Not Set"} `;
  }
}
export class ValtioExampleElement extends ValtioReaction(ExampleElement) {};

We can see how this element could simply be based on regular LitElement, and will update when reference equality of the counter property changes, or could be upgraded to support a Valtio proxy on its Counter property simply by mixing in the lit-valtio library, with WebComponents this can be done by just subclassing the default implementation of the element. This approach has proved pretty popular with the web components community since it allows you to build your components very agnostic of the state library.

Would be interested in folks thoughts on the utility of the reaction approach within valtio.

[benjamind]

Realised I didn't give a vanilla example without the web component usage:

    const state = proxy({ value: 'Example' });
    const r = reaction(() => {
        console.log(`The value is updated!`);
    });
    // track some value
    r.track(() => {
      reference.value; // read a value from the proxy to track it
    })

This approach lets you make side effects very easily. Within lit-valtio this would be hooked into the component lifecycle as follows (similar to lit-mobx implementation):

class ValtioWatchingElement extends constructor {
    private valtioReaction?: Reaction;
    
    public connectedCallback(): void {
      super.connectedCallback();
      // create a reaction that will invoke the `requestUpdate` function when tracked
      // data changes, this will drive the update lifecycle of the element
      this.valtioReaction = reaction(() => this.requestUpdate());
      if (this.hasUpdated) this.requestUpdate();
    }

    public disconnectedCallback(): void {
      super.disconnectedCallback();
      if (this.valtioReaction) {
        // cleanup when the component is disconnected
        this.valtioReaction.dispose();
        this.valtioReaction = undefined;
      }
    }

    protected update(changedProperties: PropertyValues): void {
       // use the `update` function to track proxies used in the components render
      this.valtioReaction.track(super.update.bind(this, changedProperties));
    }
  };

Users can then mixin this implementation onto any web component to make it 'valtio aware' without changing its internal render templates.

[dai-shi]

Again, thanks for the suggestion!

Not sure if I follow in detail.

Is this correct?

    const state = proxy({ value: 'Example' });
    const r = reaction(() => {
        console.log(`The value is updated!`);
    });
    // track some value
    r.track(() => {
      state.value; // read a value from the proxy to track it
    })

How can watch without get help this case?

    const state = proxy({ value: 'Example' });
    watch(() => {
      state.value // instead of get(state)
    }, () => {
        console.log(`The value is updated!`);
    });

Suppose we have another property in state, does changing it invoke the callback?

    const state = proxy({ value: 'Example', count: 0 });
    const r = reaction(() => {
        console.log(`The value is updated!`);
    });
    // track some value
    r.track(() => {
      state.value; // read a value from the proxy to track it
    })

    ++state.count // will this invoke the console log?

[benjamind]

Ah good catch, yeah this is not the intention here.

We'd really only want to call the effect callback when an observed property actually changes rather than the whole proxy. As you allude to here in the current implemention the effect will be invoked when the count property is changed even though it isn't accessed in the tracking function, and thats not ideal. For something like Lit which does referential checking on properties before render anyway this wouldn't be a major problem but it is unnecessary overhead.

[dai-shi]

@benjamind

We'd really only want to call the effect callback when an observed property actually changes rather than the whole proxy.

The philosophy of valtio is to make things simple not only in usage but also in implementation. One big design decision is its core (vanilla.ts) doesn't handle get, but only focuses on set. We don't want to hide any logic behind get. That's why adding tracking in vanilla.ts is unacceptable.

What we currently do for fine-grained reactivity is double proxies for get handler.
useSnapshot uses proxy-compare internally.
And we suggest proxyWithComputed with proxy-memoize. https://github.com/pmndrs/valtio#proxywithcomputed-util

So, in this mental model, the reaction feature should be a third-party library like valtio-reaction in the first place.

We could still explore the possibility of valtio/reaction in this repo, but not sure if it's limiting ideas. I would probably consider using double proxies in this case like useSnapshot. (If it's bad in performance, can consider the use of unstable_buildProxyFunction.)

[dai-shi]

the possibility of valtio/reaction in this repo

I feel like adding similar capability of proxy-compare in this repo is really a bad idea. So, leaning to a third-party lib.