Deprecate this package for Svelte v3?

[klaussner]

The API of this package doesn't work anymore with Svelte v3. Luckily, using Tracker with the new version much easier, so we might not need svelte-tracker anymore. Here's a small example:

import { Tracker } from "meteor/tracker";
import { onDestroy } from "svelte";

const computation = Tracker.autorun(() => {
  // Use a reactive data source ...
});

onDestroy(() => {
  computation.stop();
});

The only thing that could be simplified/abstracted even more is the onDestroy lifecycle function:

// useTracker.js

export default function useTracker(fn) {
  const computation = Tracker.autorun(() => fn());
  onDestroy(() => computation.stop());
}

import { Tracker } from "meteor/tracker";
import useTracker from "./useTracker.js";

useTracker(() => {
  // Use a reactive data source...
});

But I'm not sure if the tiny useTracker function is worth its own package. 🤔

[zimme]

Sounds reasonable 👍

[CaptainN]

I wonder if there is a way to set up custom bindings, to add that useTracker boilerplate at compile time? (I'm brand new to Svelte, but that would be sweet!)

I'm thinking something like:

t$: myThings = MyCollection.find({ ... stuff ... }).fetch();

would get turned into:

var myThings = useTracker(() => MyCollection.find({ ... stuff ... }).fetch(); );

[CaptainN]

I ended up with something slightly more complex to support SSR:

/* global Meteor */
import { Tracker } from 'meteor/tracker'
import { onDestroy } from 'svelte'

function trackClient (func) {
  // Use Tracker.nonreactive in case we are inside a Tracker Computation.
  // This can happen if someone starts rendering inside a Computation.
  // In that case, we want to opt out of the normal behavior of nested
  // Computations, where if the outer one is invalidated or stopped,
  // it stops the inner one.
  const computation = Tracker.nonreactive(() =>
    Tracker.autorun(func)
  )
  onDestroy(() => {
    computation.stop()
  })
}
function trackServer (func) {
  return func()
}

export const track = Meteor.isClient
  ? trackClient
  : trackServer

Complex enough to warrant a package?

In meteor package this would of course be simpler - one file for each linked directly to server/client.

[klaussner]

Thanks, that looks good! I haven't thought of SSR when I opened this issue.

[CaptainN]

I think trackServer needs a Tracker.nonreactive wrapper - here's the same updated:

/* global Meteor */
import { Tracker } from 'meteor/tracker'
import { onDestroy } from 'svelte'

function trackClient (func) {
  // Use Tracker.nonreactive in case we are inside a Tracker Computation.
  // This can happen if someone starts rendering inside a Computation.
  // In that case, we want to opt out of the normal behavior of nested
  // Computations, where if the outer one is invalidated or stopped,
  // it stops the inner one.
  const computation = Tracker.nonreactive(() =>
    Tracker.autorun(func)
  )
  onDestroy(() => {
    computation.stop()
  })
}
function trackServer (func) {
  return Tracker.nonreactive(func)
}

export const track = Meteor.isClient
  ? trackClient
  : trackServer

[CaptainN]

Even better - this one can react to reactive changes from svelte:

import { Tracker } from 'meteor/tracker'
import { onDestroy } from 'svelte'

function getTracker () {
    let computation
    return (func) => {
        // If we already have a computation, destroy it and start over
        if (computation) computation.stop()

        // Use Tracker.nonreactive in case we are inside a Tracker Computation.
        // This can happen if someone starts rendering inside a Computation.
        // In that case, we want to opt out of the normal behavior of nested
        // Computations, where if the outer one is invalidated or stopped,
        // it stops the inner one.
        computation = Tracker.nonreactive(() =>
            Tracker.autorun(func)
        )
    }
    onDestroy(() => {
        if (computation) computation.stop()
    })
}

Now we can recreate the computation if Svelte deps change:

<script>
    let count = 0
    let val = 0
    const track = getTracker();
    $: {
        track(function test () {
            count += val
        })
    }
    setTimeout(() => { count++ }, 1000)
    setTimeout(() => { val++ }, 2000)
</script>

<h1>{count} times!</h1>

I'll make a PR

Update: With deeper testing, this doesn't seem to work. It gets us reactivity to svelte deps, but as soon as the meteor stuff starts getting wired up, things get wacky. I'll keep at it, there's probably an elegant way to make this all play nice together.

[red-meadow]

@CaptainN, could you tell what went wrong with deep testing? I think, this is must have feature.
Also I'm curious why you didn't use computation.invalidate() instead of computation.stop()?

[CaptainN]

Getting both reactive systems to work together is what's tricky. Getting each one to work alone is easy and simple. There were just a bunch of edge cases where the changes from either Svelte or Meteor wouldn't update the component. I still think there may be a way to get it to work, but I haven't had time to work on it recently.

computation.invalidate says that one of the internal dependencies has changed. computation.stop stops and ends the computation, and cleans up all the references to so it can be GCed, which is exactly what we want when the svelte component is unmounted. For external changes (svelte reactive changes) we need to stop and rebuild the computation, so that the new (changed svelte) values are enclosed, and the reactive data sources subscribed with the old values are unsubscribed.

[red-meadow]

But is there a need to rebuild the computation each time? To enable Svelte reactivity, the func function should take values from closure anyway. I changed your code a bit and it works with the same result:

function getTracker () {
    let computation
    onDestroy(() => {
        if (computation) computation.stop()
    })
    return (func) => {
        if (computation) {
            // If we already have a computation, invalidate it
            computation.invalidate()
        }
        else {
            // Use Tracker.nonreactive in case we are inside a Tracker Computation.
            // This can happen if someone starts rendering inside a Computation.
            // In that case, we want to opt out of the normal behavior of nested
            // Computations, where if the outer one is invalidated or stopped,
            // it stops the inner one.
            computation = Tracker.nonreactive(() =>
                Tracker.autorun(func)
            )
        }
    }
}

Probably I ignore more complex cases. The one I figured out is passing callback dynamically, like track(condition ? func1 : func2), but the logic can be just moved inside the callback.

[CaptainN]

Oh, I remember why. It was more about something in react - we needed the first-run to work synchronously with render when it really was the first run (and first render) and when the deps changed. What we were getting without doing that (by just invalidating) was that for 1 render pass, the old data, derived from the old deps values would persist. This caused subtle bugs in situations where a key was not provided, and the react reconciler reused existing component instances (such as inside react router's switch blocks).

I'm not sure the same need for synchronous is needed in Svelte in response to deps changes, but if it is, then it's better to recreate the computation, because it'll run in the same event loop. (I don't think invalidate causes the next tracker run to run in the same event loop - I'd have to look through the source.)

[red-meadow]

Yes, I think I understand. I tried this and got two consecutive page updates with invalidate() while only one with stop():

<script>
...
$: {
    b++
    track(() => { sum = a + b })
}
setTimeout(() => { a++ }, 2000)
</script>

<div>{b} {sum}</div>

[red-meadow]

Sorry for spamming the thread but isn't this a solution for synchronicity? Could it be related to any of the edge cases you mentioned?

return (func) => {
    if (computation) {
      // If we already have a computation, run callback synchronously
      computation._func()
    } else {
      computation = Tracker.nonreactive(() =>
        Tracker.autorun(func)
      )
    }
  }

[CaptainN]

I think we need a set of unit tests to validate any of these approaches. It's super easy to get everything working without worrying about reacting to Svelte changes. Writing tests for that is probably the place to start.

[davidsavoie1]

I experimented with another approach to Svelte reactivity.

withTracker.js

import { Tracker } from "meteor/tracker";
import { onDestroy } from "svelte";

export default function withTracker(trackedFn) {
  const computation = Tracker.autorun(trackedFn);

  onDestroy(() => {
    computation.stop();
  });

  return computation;
}

App.svelte (script only)

import withTracker from "./withTracker.js";
import { Actions } from "/collections";

let today = false;
let completed = false;

let actions = [];
const actionsComputation = withTracker(() => {
  actions = Actions.find({ today, completed }).fetch();
});

$: {
  actionsComputation.invalidate([today, completed]);
}

withTracker returns the computation instance. The Svelte component then sets up a reactive statement that will invalidate it if any of the parameters change. computation.invalidate takes no argument, so I pass the parameters there for concision. That way, the dependencies are explicit.

What are your thoughts on this approach? It works very well so far...

[zodern]

I am experimenting with integrating with tracker by creating a svelte preprocessor.

Script tag in source file:

import { Apps } from '/imports/collections';
let count = 1;
let apps;

$m: apps = Apps.find().fetch();
$: doubled = count * 2;

After preprocessor runs:

import { getUniqueId as _m_getUniqueId, withTracker } from "meteor/svelte:compiler";
const _mId0 = _m_getUniqueId();
import { Apps } from '/imports/collections';

let apps;

$:
withTracker(_mId0, () => {
  apps = Apps.find().fetch();
});
$: doubled = count * 2;

The methods imported from svelte:compiler are:

const { onDestroy } = require('svelte');

const computations = new Map();

function withTracker (id, func) {
  if (typeof id === 'function') {
    let computation = Tracker.autorun(id);

    onDestroy(() => {
      computation.stop();
    });

    return computation;
  }

  let computation = computations.get(id);
  if (!computation) {
    computation = Tracker.autorun(func);
    computations.set(id, computation);

    onDestroy(() => {
      computation.stop();
      computations.delete(id);
    });
  } else {
    computation.invalidate();
  }

  return computation;
}

let currentId = 0;
function getUniqueId() {
  return ++currentId;
}

module.exports = {
  withTracker,
  getUniqueId
}

Labeled statements named $m are rewritten to use Tracker.autorun and have a $ label. Svelte is then able to compile them as a normal reactive statement, detecting non-tracker dependencies and handling invalidation for us. I had considered other options for the label name, but $m is short and easily distinguishable from $.

The one challenge is when svelte injects variable declarations for reactive statements. For example, in the file above, it would add let doubled to the compiled output since the reactive statement is an assignment, and the variable wasn't declared in the component. To support this feature, it will have to be implemented in the preprocessor for $m statements.

I am not sure of the next steps. Would it make sense to submit this as a PR to meteor-svelte? Or would it be better to keep it as a separate compiler package that supports the additional syntax?