Minimongo resets with multiple publications


#1

Publishing two subsets of Meteor.users with two separate publications is resetting Minimongo. Normally multiple publications should merge in Minimongo and not reset it. What I am trying to achieve is to show a list of users on a page with limited fields and detailed user profile on another page just as the many examples and tutorials found on the internet do for regular collections (Posts, recipes, movies, etc.). But in my case Minimongo just keeps on resetting when navigating between both pages. I can see the reset happening as I am visualizing Minimongo with Meteor DevTools in Chrome. Is Meteor.users collection different from regular collections? Does it have a special behavior? I have done my research but couldn’t find any helpful information. I know this could also be achieved with double subscription but haven’t tried it yet. I would first like to understand why the double publication isn’t working as expected (merging rather then resetting). Any help ?


#2

Are your subscriptions scoped to your templates? If so, I’d expect that the subscriptions would be dumped when the template is destroyed, unless you are using a subscription cache.

In your use case, it sounds like you would be:

  1. subbed to the list of users with basic details, and then on click,
  2. subbed to the detail of one user, and then on back,
  3. subbed back to the list of users

So there would be no merging in this case.


#3

I am using React. How can subscriptions be scoped to a template/page ? Here is an extract of my code.

// publications.js 
Meteor.startup( () => {

  Meteor.publish('allProfiles', function (limit) {
    if (this.userId) {
      return Meteor.users.find({}, {fields: {username: 1}, limit}); 
    } else {
      return [];
    }
  });

 Meteor.publish('oneProfile', function (profileId) {
    if (this.userId) {
      return Meteor.users.find({_id: profileId}); 
    } else {
      return [];
    }
  });

});

// all_profiles_page.js
// showing here only the container
export default withTracker ( () => {
  const subscription = Meteor.subscribe ('allProfiles', 50);
  const loading = !subscription.ready();
  const profiles = Meteor.users.find({}).fetch();

  return { loading, profiles };
})(AllProfiles);

// one_profile_page.js
// showing here only the container
export default withTracker ( (props) => {
  const { profileId } = props.params;
  const subscription = Meteor.subscribe ('oneProfile', profileId );
  const loading = !subscription.ready();
  const profile = Meteor.users.find( {_id: profileId} ).fetch();

  return { loading, profile };
})(OneProfile);

#4

Ah, my bad, I was talking blaze.

If your components are unmounting, then the subscriptions will be cleaned up when that happens. I’m assuming this is the case, since it looks like the components are on different routes?


#5

Yes the components are on different routes. How can I avoid cleaning up subscriptions ? This behavior is not optimal performance wise. In this case every time the user navigates back to the profiles list page the entire list is sent back on the wire.


#6

I’d check out something like this.


#7

This seems what I need. Thanks I’ll check it.