The biggest problem here is not how much data you store in the browser. The biggest one is Meteor maintains reactive data. Imagine by switching to different pages (routes) you subscribe to thousands of documents, you will put a heavy load on your server.
If you just want to store data in minimongo, you can use methods to load data and store them in local collection manually. They will be there until you clear them. Of-course it’s not easy as the one you’re talking about.
useTracker should be thought of as a client for Tracker - whatever Tracker does behind the scenes is still what it does when using useTracker.
Honestly, Tracker does a bunch of stuff that is kind of hard to deal with. For example, it has it’s own mechanism for recycling subscriptions. This comes with a lot of benefits - if you change routes, the subscription won’t be immediately destroyed, and if the new route uses a similar subscription, you may save some bandwidth, and have a more responsive app.
In useFind we don’t use any of that. We use a computation directly, without a Tracker wrapping it. And it updates a top level immutable array (is partial immutability a thing?), to make re-rendering lightening fast if your iterator components are memoized.
As far as expiring documents - in React apps, that should be managed by your needs in react or through some other type of custom management solution. There’s nothing stopping you from putting useTracker or useFind anywhere you like in your tree, and dealing with the data however you want to deal with it. But for more specific types of expiry, you’ll need to roll your own data management solutions.
1 Like