Reactive-Publish for Meteor 3: Revived and Ready for Composite Data Publishing

announce
1

Hello everyone!

Great news for those still migrating to Meteor 3 and blocked by peerlibrary:reactive-publish.

nachocodoner:reactive-publish is the modern version with async support. This package is an alternative to reywood:publish-composite. Feel free to use this solution to publish composite data.

I decided to revive it, since I use it in my Meteor 2 hobby apps. With the core updated and modern tools arriving, I found time to move my apps to Meteor 3 over last months. The last hurdle was peerlibrary:reactive-publish. You can read about why I keep using it here.

The package is now in alpha and the full test suite passes :white_check_mark:. I’ve integrated it into my apps, and all tests are green. I’ll release a beta once I confirm that Meteor core tests aren’t affected by the changes to core publish and other modules, but so far both package tests and my app tests pass.

I’d appreciate feedback from anyone who needs it or wants to try it. Are your tests passing? I published early to address the requests from Reactive publish using async collection functions.

Hands on

meteor add nachocodoner:reactive-publish@1.0.0-alpha.2

Basic usage

The package makes any changes in your queries inside an autorun block publish updated data reactively, even for linked collections.

Because of isomorphism and minimongo, you can reuse the same code on client and server. This keeps your query logic unified, one of the main benefits over publish-composite.

Meteor.publish('subscribed-posts', function () {
  this.autorun(async () => {
    const user = await User.findOneAsync(this.userId, {
      fields: { subscribedPosts: 1 },
    });

    return Posts.find({ _id: { $in: user?.subscribedPosts || [] } });
  });
});

In the example above, you publish the user’s subscribed posts. When the User’s subscribedPosts field changes, autorun reruns and publishes the updated posts. Any queries with related data work the same way. You can also publish an array of cursors and use the same logic as in a normal publication body.

The package and more details are on GitHub: nachocodoner:reactive-publish

Roadmap

Current version: 1.0.0-alpha.2. I’ll update this post with future releases.

  • Stability

    • Ensure core changes in this package don’t affect Meteor core tests
    • Release betas and RCs, with a feedback period for early adopters

  • Expansion

    • Support for AsyncTracker and ReactiveVarAsync on the client
    • Migrate peerlibrary:subscription-data to support publishing derived data reactively

  • Performance

:comet: Keep going with Meteor 3 and building cool apps!

11 Likes
2

I’d be really intrigued if it beats reywood:publish-composite in terms of performance. publish-composite API/DX is very grotesque and feels unnatural compared to reactive-publish.

1 Like
3

Thanks a lot for your work! Works perfectly here with a bunch of filtered published collections, with no changes other than the async/await makeover. Could not see any change in runtime behavior.

1 Like
4

Awesome! Does that mean that reactivity works on several nested levels? This was the main drawback with reywood:publish-composite for me, since reactivity only worked on top level.

2 Likes
5

Works fine for my app, tx very much @nachocodoner :pray:

1 Like
6

Anything inside autorun runs reactively, so you can prepare cursors for multiple collections depending on related fields got from Mongo operations in the same autorun body.

Does that answer your question? I’m not very familiar with the internals of publish-composite, but I think you mean the limits of nested relationships there? in reative-publish you programatically describe all relationships and cursor without any limits.

7

That’s pretty cool, thanks! Yes, publish-composite only reacts on changes on the top-most query.

1 Like