How can I use TrackerReact with Layout?

help
1

At the moment I have added the TrackerReact composition to the components that need it. But, I just found that my app needs two collections to basically be ready no matter the route I choose. I am worried that switching routes will unsubscribe and then subscribe these two collections, without this beeing needed. Due to this I started investigating moving the TrackerReact composer higher up in the chain, as in actually wanting it to wrap the entire layout component.

Questions:

  1. Am I worrying unnecessarily, or will the unsubscribe followed by a subscribe for the same collection indeed empty it on the client and then refetch it from the server, as I think it will/should?
  2. How can I use TrackerReact to compose a Layout (I am using react-mounter). I could not find any examples for this online.
2

An unsubscribe followed by a subscribe to the same data is essentially a null operation:

If the subscription is run with the same arguments then the “new” subscription discovers the old “marked for destruction” subscription that’s sitting around, with the same data already ready, and simply reuses that.

3

Cool. Thanks.

I wish the docs would have stated how long the “marked for destruction” collection will be kept though. The steps from the resource you linked says:

Technically, what happens when one of these reactive sources changes is the following:

  1. The reactive data source invalidates the autorun computation (marks it so that it re-runs in the next Tracker flush cycle).
  2. The subscription detects this, and given that anything is possible in next computation run, marks itself for destruction.
  3. The computation re-runs, with .subscribe() being re-called either with the same or different arguments.
  4. If the subscription is run with the same arguments then the “new” subscription discovers the old “marked for destruction” subscription that’s sitting around, with the same data already ready, and simply reuses that.
  5. If the subscription is run with different arguments, then a new subscription is created, which connects to the publication on the server.
  6. At the end of the flush cycle (i.e. after the computation is done re-running), the old subscription checks to see if it was re-used, and if not, sends a message to the server to tell the server to shut it down.

Step 4 above is an important detail—that the system cleverly knows not to re-subscribe if the autorun re-runs and subscribes with the exact same arguments. This holds true even if the new subscription is set up somewhere else in the template hierarchy. For example, if a user navigates between two pages that both subscribe to the exact same subscription, the same mechanism will kick in and no unnecessary subscribing will happen.

As it is now, I feel that I can have no certainty in that the subscription will not flush and re-fetch. But, it seems that I can have a somehow validated expectation that it should persist the collection from the subscription…

4

That’s right. The use case in the Guide is specifically written around a reactive subscription change, where we might reasonably expect that the unsubscribe is followed “instantly” by the subscribe.

However, you can subscribe to as many publications as you want - so why not subscribe to both?

5

Thanks. That is kinda what I will end up doing actually.

1 Like