Error: Can't set timers inside simulations?

[trusktr]

@jam

I still struggle with a real world scenario where wrapping a method in Tracker.autorun would be super useful.

It’s “signals and effects”. Once one knows the power of signals and effect patterns, they’ll realize the wonder of being able to wrap a function in an effect. This is what we easily had in older Meteor.

I’m not sure what are some good articles to point you to for signals and effects patterns, but diving into Solid.js might help. Patterns across the ecosystem have adopted Signals and Effects (something Meteor has had for ages, but it was named autorun (computations) and reactive vars rather than effects and signals) because people are realizing how powerful yet simple they are.

I started to hint at the benefits here: Synchronous Collection methods removed from Meteor, now we need async signals

@jam

I suppose it’s because I’m used to using pub-sub for my reads and methods for my writes so everything remains reactive and isomorphic. Maybe you or someone else can enlighten me.

I’m not quite sure what you mean. Subscriptions (Meteor.subscribe) are not for reading, but for requesting certain data be synced to the client. The way that you read that data is via the Collections API, or Meteor.methods. Collections and Meteor.methods are also used for writing (but you cannot use Collections or Meteor.methods without first calling subscribe so that data will become available for reading).

Once you’ve enabled certain data via Meteor.publish (backend) and Meteor.subscribe (client) then you can use methods. This has been true since the beginning of Meteor time. The only difference between then, and now, is that Meteor.methods are no longer easily isomorphic while still being reactive (publications and subcriptions have no bearing on that).

@jam

For the specific example you gave above I’d do this on the svelte frontend instead of having someMethod:

$m: Meteor.subscribe('booksAndAuthors')
$m: booksCount = Books.find({}).count()
$m: authorsCount = Authors.find({}).count()

Yes, that works. I think you may be missing what I’m saying because perhaps it is something you haven’t tried before? What I’m describing is that (in the past, before the promise-based APIs, while we were on synchronous-style Fibers code), a Meteor.method was basically “just a function” and it didn’t matter if you called it on backend or frontend, and it also (this is the key) worked inside Tracker.autorun (or with Svelte integration, inside $m blocks if you look at it that way).

In the past, it was easy to have an isomorphic function like this:

Meteor.methods({
  // This function is used in both the server and the client in various places (in pre-Promise Meteor)
  stats() {
    return `There are ${Books.find({}).count())} books and ${Authors.find({}).count())} authors.`
  }
})

And then a client could use it like this:

$m: Meteor.subscribe('booksAndAuthors')
$m: stats = Meteor.call('stats')

where this “stats” function could be called on the server or the client, and additionally if it was called on the client it could be used reactively. That was a great thing, and that’s what is now missing (or it is now more difficult to do, or requires splitting code up into separate server vs client pieces).

That’s only a simple example. Imagine an app with large amounts of reactive isomorphic “just function” code that uses the code on both backend and frontend. It will be a pain to refactor into modern Meteor.

Also, I want to write this type of isomorphic reactive code. It’s the beauty of Signals and Effects, being able to group logic together like this. Yes, I can split my code into pieces for frontend and backend, to workaround the Meteor requirement of promises on backend, but I’m just saying that it’s less ideal to have to do so.

@ceigey

Would a workaround be to make a synchronous query in the autorun callback on the relevant collection and use that to trigger the necessary Meteor method call?

That’s the thing: yeah, there are workarounds like I just described in the previous reply to Jam, such as splitting isomorphic code into server vs client pieces rather isomorphic pieces, because it is now necessary. I’m only saying that it wasn’t required before, and that it was actually a really nice thing to be able to write isomorphic also-reactive code.

@ceigey

(I haven’t tested this and I’m embarrassed to say I haven’t been working much with pub sub recently!)

That’s ok, but note that this isn’t really related to pubsub as I’ve described for Jam. Pubsub served the same purpose before the promise-based API as it does now, nothing has changed with pubsub in that regard. This is only describing how Meteor.methods work, and the fact that they are no longer isomorphically reactive (without having to use difficult workarounds like Tracker.withComputation for every reactive site, which also opens up a potential bag of other async race condition issues that are maybe subtle and more difficult to debug).