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:
- The reactive data source invalidates the autorun computation (marks it so that it re-runs in the next Tracker flush cycle).
- The subscription detects this, and given that anything is possible in next computation run, marks itself for destruction.
- The computation re-runs, with
.subscribe() being re-called either with the same or different arguments.
- 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.
- If the subscription is run with different arguments, then a new subscription is created, which connects to the publication on the server.
- 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…