Reactivity Interoperability

[3Shain]

• Start Date: 2021-12-16
• Target Major Version: 3.x
• Reference Issues: (fill in existing related issues, if any)
• Implementation PR: (leave this empty)

Summary

Introducing a new addReactivityInterop() API for @vue/reactivity. This feature adds support for (one-way) reactivity interoperability with third party libraries.

Basic example

// file: store.js

// use mobx as a demostration of external reactivity source
import { Reaction, makeAutoObservable } from 'mobx'

// register MobX
// this step should usually be performed by _library authors_.
let id = 0
addReactivityInterop((fn, trigger) => {
  const reaction = new Reaction(`externalSource@${++id}`, trigger)
  return {
    track: (x) => {
      let next
      reaction.track(() => (next = fn(x)))
      return next
    },
    dispose: () => reaction.dispose()
  }
})

// user-land mobx store
class Timer {
  secondsPassed = 0

  constructor() {
    makeAutoObservable(this)
  }

  increase() {
    this.secondsPassed += 1
  }

  reset() {
    this.secondsPassed = 0
  }
}

export const timer = new Timer();

setInterval(() => {
    timer.increase();
}, 1000);

In vue component:

<script setup>
  import { timer } from './store.js'

  const doubled = computed(() => timer.secondPassed * 2) //even this is possible!
</script>
<template>
  <button @click="timer.reset()">
    Second passed: {{ timer.secondsPassed }}, doubled: {{ doubled }}
  </button>
</template>

Motivation

It adds a lot of convinient, eliminates annoying wrappers (e.g. convert to a ref) and we can use third party reactive objects as if they are first-class citizen in vue.

This feature is primarily for library authors. Normal users do not need to worry about this.

Detailed design

API Summary

// pending deisgn
type InteropSource<T> = { track: ()=>T , dispose: ()=>void };
type InteropSourceFactory = <T>(fn: ()=>T, trigger: ()=> void) => InteropSource<T>;

function addReactivityInterop(factory: InteropSourceFactory): void;

Implementation

Currently addReactivityInterop will perform irreversible side effect: setting the current InteropSourceFactory (which should be a global variable).

Whenever a ReactiveEffect is constructed, the current InteropSourceFactory should be called with the original fn passed in ReactiveEffect.constructor and a trigger function which trigger the ReactiveEffect (to be scheduled/re-run). The return value is a InteropSource, whose .track should replace .fn of current ReactiveEffect and .dispose() should be called whenever current ReactiveEffect will be cleaned up. Essentially there are two steps:

• Hook ReactiveEffect.fn, so third party libraries get the control to perform their own dependency tracking logic.
• Cleanup whenever appropriate, to avoid memory leak.

Note this feature implies the (external) dependencies should be transparently collected (by external) and the control should be NOT inversed by external (it's vue taking control at first, calling the third party code to perform their dependency tracking). However, not all reactivity implementations give user the control (usually the control is inversed, e.g. computed(getter) whose getter is called by framework, not user directly, while mobx's Reaction.track(fn) is called by user, and runs immediately) or support auto (transparent/implicit) dependency tracking.

It's possible to implement auto dependency tracking and/or auto subscription based on a reactivity implementation which doesn't support these features, yet it's not the topic of this RFC.

Workaround

In vue 3.2+ there is a work-around by patching ReactiveEffect

let currentInteropSourceFactory:InteropSourceFactory | null; // set by `addReactivityInterop`

Object.defineProperty(ReactiveEffect.prototype, 'fn', {
  get(this: ReactiveEffect & PatchedReactiveEffect) {
    return this._fn
  },
  set(this: ReactiveEffect & PatchedReactiveEffect, originalFn) {
    if(currentInteropSourceFactory) {
      if (this._fn) {
        this._interopSource?.dispose()
      } else {
        this._signal = ref(undefined)
      }
      this._interopSource = currentInteropSourceFactory(originalFn,()=>triggerRef(this._signal));
      this._fn = () => {
        this._signal.value; // track in vue
        return this._interopSource.track();
      } 
    } else {
      this._fn = originalFn;
    }
  }
})

const origianlStop = ReactiveEffect.prototype.stop

Object.defineProperty(ReactiveEffect.prototype, 'stop', {
  value: function (this: ReactiveEffect & PatchedReactiveEffect) {
    this._interopSource?.dispose();
    this._interopSource = null;
    origianlStop.call(this);
  }
});

interface PatchedReactiveEffect {
  _interopSource?: InteropSource;
  _fn?: Function;
  _signal?: Ref<any>;
}

Composed InteropSourceFactory

If addReactivityInterop is called multiple times, the current InteropSourceFactory should be composed.

Drawbacks

• A bit of magic (but acceptable in the context of vue)
• Add a bit of performance overhead in creation of ReactiveEffect

Alternatives

N/A

Adoption strategy

This is a new API and should not affect the existing code. It's also a low-level API only intended for advanced users and library authors.

Unresolved questions

• Better API naming?

[3Shain]

Playground

A similar implementation (not in vue), for reference: solidjs/solid#739

[jods4]

Wouldn't that problem be solved more simply by making track and trigger (from @vue/reactivity) public APIs?

As a bonus side-effect it would enable creating custom/more efficient reactive objects/primitives; and it would allow other reactive systems such as MobX to integrate into Vue reactivity.

I have proposed this in the past and Evan was opposed to making trigger and track stable, public APIs; but this proposal is also exposing the trigger and track concepts (under those exact names), wrapped inside different objects, so it's really not any higher-level.

(Note: trigger and track could actually be used today; it's just that Evan said it's not officially a public API and stability is not guaranteed for future releases)

[3Shain]

import { makeObservable, observable, computed, autorun } from "mobx"

class OrderLine {
    price = 0
    amount = 1

    constructor(price) {
        makeObservable(this, {
            price: observable,
            amount: observable,
            total: computed
        })
        this.price = price
    }

    get total() {
        return this.price * this.amount
    }
}

const order = new OrderLine(0)

how is order.total be tracked without setting-up a subscription? If it's never subscribed, it will be never notified by the change from price & amount. Unlike vue's computed is always alive given it's always created under an EffectScope.

Indirectly tracking price & amount (as they are the 'sources' and don't require subscription)? Then mobx's computation is just useless. (but it should be useful, because of on-demand subscription & memo)

[jods4]

It's a good point, that make the complete solution a little more involved but still doable.

The problem of course is not to start the computation, which works easily enough, but to be able to stop it as Vue doesn't have a public API for dropping effect dependencies.

I think the most straightforward way to do this is to let MobX do the bookkeeping.

Based on my most recent idea, i.e. create custom trackingContext and trackingDerivation:
If we base vueContext and vueDerivation on the existing Mobx code, it already does all the bookkeeping.
Those context and derivation only need to be modified to add extra track / trigger calls.

Concretely the code changes compared to the existing contexts and derivations would be:

• Call Vue track when calling addObserver in the derivation;
• The derivation onBecomeStale_ should call trigger.

---

EDIT: a few considerations on this idea:

1. There is a double book-keeping going on when a MobX object becomes a Vue dependency, as both MobX and Vue keep track of dependencies. To avoid this, Vue would have to make its dependency management public, I guess at least a hook when a dependency is removed from an effect (not sure it's worth it).
2. The naive implementation described here creates a context + derivation for every Vue effectScope, even when most of them wouldn't need it. This could be avoided by making them lazy: monkey-patch properties on globalState that only create them lazily when a MobX object was called, so no work is done when an effect runs 100% in Vue code.

[3Shain]

That's different from your initial idea.

Anyway non-intrusiveness is my bottom line. Perf impact should be experimented by benchmarks. There are trade-offs (and vue is essentially an art of trade-offs), you gain something then you lose something. This proposal is not perf oriented. If someone really need great perf, they shouldn't consider interoperability too much.

[jods4]

That's different from your initial idea.

Not that much.
The minute details of where the code goes are different, but code itself is not that important.

My fundamental question was: aren't trigger / track enough?

To be transparent, I have my own motivations for asking this question:
I've mentioned it before but I think you can do many interesting things when given access to track and trigger, outside the scope of interop with other libs. There's currently another discussion that basically amounts to exposing the shape of track and trigger: #364

Minimizing the amount of public API when possible is definitely a good idea.

[3Shain]

My conclusion is 'not enough' but I have no responsibility to prove it :). Please tell me if you find one which is not intrusive.

P.S. I will not reply a word until there is a real implementation (a playground or a repo)

[jods4]

There are two things that I don't find elegant in your proposal:

1. My understanding is that it only works with a single 3rd party lib.
   For example if I'm migrating to Vue a legacy app that was written in Knockout with MobX added, then I couldn't hook both KO and MobX into this system.

2. It is taxing perf and memory-wise.
   Effects are at the heart of Vue, in a large app there are lots of them: one for every component, one for every computed (and man some libs, e.g. validation, create tons of computed).
   There was some effort into optimizing them.
   Once a 3rd party is integrated, each effect will run inside a 3rd party "effect" (Reaction in MobX).

Sadly, I don't see how to improve those points without having the 3rd party lib cooperate :(

[3Shain]

Composed InteropSourceFactory
If addReactivityInterop is called multiple times, the current InteropSourceFactory should be composed.

True. Not able to solve until there is a working alternative