Integration between Vue reactivity and Tracker reactivity

[mitar]

I am looking a bit how you are integrating Tracker with Vue and maybe I am misunderstanding something, it does not yet work as one would expect from perfect integration, because Vue reactivity is not really integrated with Tracker reactivity, no? So you cannot really use inside methods both Tracker reactive functions and access data and expect things to rerun, no?

Luckily, it seems that Vue reactivity has a similar model to Tracker reactivity. It also seems that Vue's state tracking is just a mixin.

Here are some random ideas what we could do:

• for Meteor Vue components (or it could be an optional mixin), we could make it so that when Vue augments data with getters, we make them also Tracker getters (so when you set it, you invalidate both Vue and Tracker dependencies)
• we could monkey-patch Vue Dep to make it interact with Tracker.Dependency, APIs are really similar
• but we probably do not care really that changes which happen inside Tracker dependencies are run on Tracker queue, we probably only want to provide the same API to reactive Meteor code so that it thinks it is running inside autorun, but it fact it is interacting with Vue Dep (and we leave to Vue to run it inside its own queue); this means that inside Vue, we could maybe misuse Tracker.active to set it to a fake computation which interacts with current Vue Dep
• for Minimongo integration, I wanted for a long time to make something there which would make it so that it is not needed to specify fields on the query to limit reactivity, but it would be limited automatically by the fact that you would use some values and not others, it seems that this could be very well integrated with Vue
• we should see how Vue wraps mutation objects on arrays and make it so that Minimongo changes trigger those mutations on Vue

What are your thoughts what is missing here for proper Meteor integration?

[Akryum]

Hey @mitar , a lot of useful thoughts on the integration. will definitively help with a potential vue-powered blaze! 👍

I initially decided to separate the Tracker and Vue reactive callbacks because I had very obscure issues by merging them into one callback (like other integrations does - and those I tried had similar issues). This caused unecessary/duplicate updates. I agree that we need to rethink the tracking integration and maybe completely replace Tracker internals with Vue Dep system.

[mitar]

So what I am currently thinking is that probably it would be better if we get Tracker and Minimongo to properly integrate with Vue, and then offer Blaze as a preprocessor (similar to how Jade is done for Vue). It would not be completely the same as Blaze 1.0, but it could have similar Handlebars syntax. Probably we would just name it Handlebars and not really Blaze. So Handlebars preprocessor for Vue.

[mitar]

BTW, do you know where is reactivity on accessing data in Vue registered? Looking at this proxy I do not really get it.

[Akryum]

Vue setups special getters and setters that are wired to a Watcher instance that keep track of every other instances that use the getters, and the setters wake them up (plus Array methods like push). There is section about reactivity in the guide.

[mitar]

Yes, I was more curious in the code, where this happens. Because I do not see that this proxy is in any way special. propse use defineReactive, but not data.

[Akryum]

Because the data properties are stored inside a $data reactive object (see here), that are then proxied to the component instance (see here).

[mitar]

Hm, I think it is this call which makes it reactive. OK.

[mitar]

I made progress. I have full Tracker compatibility version implemented on top of Vue's observer:

• it needs for now a fork of Vue: Necessary changes to observer for full Tracker compatibility vuejs/vue#4652
• code: https://github.com/mitar/vue-test/blob/master/packages/tracker/tracker.js
• example app: https://github.com/mitar/vue-test (notice how I can use Meteor ReactiveVar inside computed value directly)

[mitar]

It would be great if Meteor supported overriding packages. Because for now the only way to override the package is to put it inside packages. But this is not really a nice way to distribute this new implementation of Tracker.

[Akryum]

So far, you absolutely need those Vue changes?

[mitar]

Depending what the goal is. For 100% compatibility, probably yes. I definitely need access to Vue and Watcher symbols. Now, we could probably monkey patch more. The issue is the lack of support for after flush callbacks and the while loop around.

[Akryum]

Maybe nextTick could do?

[mitar]

Depending if we want 100% compatibility with Tracker and the same order of how dependencies are processed (especially outside rendering/Blaze/Vue dependencies).

One option I was considering initially was that we would have two queues, Tracker and Vue, and then just integrate Tracker's dependency with Vue dependency objects. The downside with this is that Vue would not invalidate Tracker's context then. So it would be only one directional. Now it works in both directions. You could have something like:

count() {
  Tracker.autorun(() => {
    counter.set(this.buttonLabel);
  });
  return counter.get();
}

And it would work. (No reason why one would do something like this, just an example.) When buttonLabel would change, autorun would rerun. When outside count would get invalidated, internal autorun would stop. Exactly how one was used in Meteor/Blaze/Tracker.

I think this is really powerful.