if (Meteor.isServer) {
Meteor.publish('sites', function () {
if (!Meteor.userId()) {
Meteor.Error('not-authorized', 'You must be logged in to view this data')
}
return SitesCollection.find()
})
}
Client code:
Tracker.autorun(() => {
console.log('[TRACKER] Update')
const subscription = Meteor.subscribe('sites')
if (!subscription.ready()) {
console.log('[TRACKER] Sites subscription not ready.')
return
}
const data = SitesCollection
.find({ 'zone._id': workingZone() }) // Solid.JS signal
.fetch()
console.log('[TRACKER] Sites data:', data)
setSitesRows(data) // Solid.JS signal
setReady(true) // Solid.JS signal
})
The tracker function is run only once. If I insert a new Site using a server Meteor method, the document is inserted normally, but the Tracker does not react. The same code works perfectly in Meteor 2.15.
If I trigger another find/fetch, with a button for instance, the inserted document appears, so the pub/sub is working. It’s just the Tracker is not reacting.
Hi! I’m just looking over this, and have nothing specific… but some things to think about / try out maybe?
a) you have the subscription IN the autorun - which you don’t need. you could rather subscribe outside the subscription. In a blaze template you could use Template.instance().subscribe(…) to make sure the subscription is ended once the template has been destroyed… but in general, you don’t need the subscription in the autorun. Just subscribe outside / before the autorun; and the .find() should be reactive when the sub gets its results in.
b) Another question: if you feed in a fixed zone._id (?) (is the field name right?) → It’ll be scoped to results for this specific zone.id, no? Only one document? Or does workingZone() return an array or something? Is workingZone itself a reactive data source?
My question is, if you add a new site, would it have the same zone._id previously set? So there are multiple zones in the same site? Is that correct?
If so then that is good, might still be worth to log workingZone() maybe (?). How is Solid.JS? Is it nice? Should I use it?
c) In general there was a lot of shenanigans going on with meteor 3 and the transition to async / await on the client AND the server to keep the syntax isomorphic.
Thus you could turn your autorun function into an async function () => {} just to test it, and try using the async versions (const res = await coll.find().fetchAsync()
d) With async there is also the thing with multiple reactive fields needing a Tracker.withComputation wrapper from the second reactive data source call on: Tracker | Docs (it’s complicated). You don’t use the async functions, so you should be good. But still. Good to know maybe?
There’s this plugin I wrote to enable reactive dependencies without explicit Tracker.withComputation calls as well as nested calls (calls to functions which then peruse reactive data sources): babel-plugin-meteor-tracker-async-enhance - npm which is my magnum opus for the meteor 3 transition
Not sure if any of this is helpful, but I sure did try!
a. I get the same behavior having the subscription either inside or outside the Tracker.
b. workingZone() is a Solid.JS signal (reactive/state variable). It can change, but I’m testing without changing that value. If I react to a change to that signal (createEffect), everything works ok: I get a different Site list according to the new value. Like so:
It’s a bit surprising that you needed it, given you’ve been using the synchronous functions - but maybe someone else can provide some insight here. I think the main focus is now on the async variants of the different Tracker functions.