Handling Subscriptions in my Templates [solved]

help
1

I have an issue that I think has an easy solution, I am just having trouble with it for whatever reason.

I have a template like so:

<template name="ParentTemplate">
    {{> ChildTemplate}}
</template>

I am trying to subscribe to the same set of data in the two templates, but I don’t want the parent template to access the child templates subscription. Currently I have it set up like so:

Template.ChildTemplate.created = function () {
    this.subscribe('all_of_the_data');
};

Template.ParentTemplate.rendered = function () {
    this.subscribe('part_of_the_data');
};

I don’t want the parent template to access ALL of the data - only part of it, but it is accessing the child templates subscription. I am not sure how to set it up so it doesn’t, if possible. I am using Iron Router if that helps.

2

There’s no such thing as accessing subscriptions.

Active subscriptions, wherever they are created, collectively ask for data and the server computes the most optimal sets for each of them and finally on the client all the incomong data from all the subscriptions get merged into the same collections.

So it is your job to create necessary helpers on each template to feed the exact data you need and the way to do that os write find() queries.

A more advanced and verbose way would be to create alternative client side collections and publish to those but that’s a scenario that should be used when you actually cannot do away whin helpers and queries.

Of course I can give you a more precise answer if you share your actual use case and what you want to “separate”

3

Okay that makes sense.
Basically, the child template displays a count of the data and the parent template is a list of the data. Since the list can be very long, I wanted to paginate it. But then the count only displays what is shown in the current pagination set. But I guess I can just subscribe to all the data and then paginate it in the helper, but I thought it was better to paginate in the publication.

4

Oh yes, if we are in “pagination” territory, it is always best to paginate the data at its source, which is the publication on the server itself.

But beware of merging woes where the paginated data can be “polluted” by another subscription so you may end up having “11” lines of data when you were expecting “10”.

The best way perhaps then, to keep a pagination style display isolated, would actually be the technique I referred to in my first reply. Using alternate client side colllections to feed the data into.

Take a look at this and this

1 Like
5

Thanks, I think this is what I was looking for!

6

I just want to say Thank You again for your help. I have updated my code and the client side collection is working perfectly! It’s exactly what I needed.

Although the links you left me didn’t help me that much I used these: eventedMind Video & Stack Overflow question two resources I found after Googling about client side collections. Neither of those really pertained to my situation specifically either but helped me figure it out :wink:

1 Like
7

Great! It’s all the best if you had to do most of the work to figure the thing out, now that you will never forget them and have a core understanding of the inner workings :smile:

1 Like