Non reactive publications in meteor

help
1

How to create non reactive publications in meteor?

I have few documents in one collection and I want to send the data to client on first load and I don’t want to receive new updates in client, how to do this?

I tried simply {reactive: false}

Meteor.publish('industries', function () {
  return Industry.find({},{reactive: false})
});

but looks like {reactive: false} is client side options.

I can give this options to the cursor wherever I’m using the cursor, but still I doubt that server sends data reactively.
I don’t want to waste the server memory (merge box storage where it keeps track of that data).

I know I can use meteor methods, but I’m using this subscription lot of places in my app like 10-20 times so rewriting is bit of work.

Is there any simple way to do this like adding {reactive: false} options

there may be lot of use cases where user don’t need reactivity in publications I think.

1 Like
2

Here is a way to make a non-reactive subscription.
Use fast-render and remove Meteor.subscribe() altogether.
You will get data injected into HTML on the client, but technically never subscribe to it on the server.

3

Maybe you can subscribe, copy the data to somewhere (for example a local collection), then stop the subscription?

4

IMHO the better way to do this is to skip subscriptions all together. Just create a Meteor method that returns the same data that the publication would (just make sure to call fetch so you don’t return the cursor). You’ll need to use the same permissions checks if it has sensitive data.

Blonk does this with the jobs ‘feed’ so that when you’re swiping the card doesn’t change while you’re swiping (makes it jitter).

If you need to persist the data on a hot reload you can use Session or a reactive dict to store it in.

5 Likes
5

Retrieving data through methods may become a real headache. Spent whole evening sorting this stuff out.
Ended up finding this fine package by @msavin.

1 Like
6

You can make use of the publication added method. Take a look here: http://meteorcapture.com/publishing-anything/

1 Like
7

But I guess this will produce reactivity, which is not needed in our case?

1 Like
8

It depends on what you’re calling reactivity here. In my example you’ll receive the initial document set and no subsequent updated or removed messages, so the data will remain static on the client end.

1 Like
9

Your blog post is about getting data from a 3rd party API, which isn’t reactive, I assume.
But can you make a publication non-reactive coming from native Meteor Mongo instance with .added?

10

Of course, just do something like:

Foo = new Mongo.Collection('foo');

Meteor.publish('example', function() {
  var self = this;
  var docs = Foo.find().fetch();
  _.each(docs, function(doc) {
    self.added('foo', doc._id, doc);
  });
  self.ready();
});
1 Like
11

…mmm, let me guess - Foo = new Mongo.Collection('foo'); sd be declared client-only and that is what makes this pub static?

12

Not in this case as we’re grabbing data from the collection within the publication (which is on the server). What makes the example “non reactive” is that we’re only sending added messages once after initially subscribing.

Have a read of the publish and subscribe section of the docs http://docs.meteor.com/#/full/publishandsubscribe

1 Like
13

Does this method of publishing incurs server overhead for maintaining the publication? (like for reactive pubs)
Say, if 10K clients will subscribe, will the server require more RAM and CPU?

1 Like
14

I would guess that is likely

15

David, curious, how would you update this code in a 1.3 / ES6 world?

16

I think methods is the way to do it as mentioned by @SkinnyGeek1010

1 Like
17

Like this

Meteor.publish('example', function() {
  const docs = Foo.find().fetch();
  docs.forEach(doc => this.added('foo', doc._id, doc));
  this.ready();
});
1 Like
18

FWIW (ideally) if you’re starting from scratch today I would recommend getting into Apollo and use the GraphQL mutations… it’s kind of like a combo of simple-schema and meteor methods (the schema determines what the client is allowed to get back). However I realize that’s a lot of overhead for some but yeah Meteor methods have served me very well over the years!

2 Likes
19

Sorry to revive this topic, but the docs state that when using Collection.find({},{reactive: false}) on the client would disable reactivity.

Can someone confirm this? It doesn’t work with my app (1.3.5.1).

20

I have created a small use case and switching off reactivity works as documented.

1 Like