Hi i try use meteor with react and i use @reach router exactly like react router.
my problem is this.
With meteor and Blaze my minimongo when load data persist when i change page in react my minimongo is reset and so i must resubscribe my data.
Why what is the reason what is best practise?
This is a really big problem and the overall performance of the software goes down.
I have the same problem.
Really guide friends.
@filipenevola In fact, the previous data should not be deleted when the words are changed.
Why is that?
I have found solution!
I i call subscription in useTracker Hook this exist only in route select if a change page the value is reset.
If i call external to useTracker the data persist in change page!
@gladenko
I did not understand you correctly
I also use a use tracker to subscribe data. But by changing the routes, the data is taken from the beginning. Even if I go to the previous path, I still see loading displayed, loading due to not preparing the data.
Please show by example. Thankful
It’s how it works and it should work that way.
When a react component is mounted, its runs all subscriptions (useTracker). When it’s unmounted, all the data clear automatically. You will have a big trouble if the data wasn’t got clean, your local data got bigger and bigger then it will crash the browser.
If you want a subscription persistent, you can move the subscription code to a component which won’t be unmounted when your router changed.
It is not a good experience for the user to retrieve data from the server from the beginning with each root change.
@minhna At least it can hold the information and data of a previous root only. Not all routes.
It’s a combination of what you say and a good user experience.
I agree that re-fetching all data from the beginning is not ideal.
useTracker needs to be updated so that it will clean up data in the future after some time, if no component needs it, instead of cleaning right away. Perhaps it needs to use a setTimeout. Or, if route switching is fast enough, just queueMicrotask (I’m not sure, I don’t use React, try Solid.js 
).
With deferred cleanup, this problem will mostly go away, except in cases where someone switches away from a page that uses the data for long enough time period, then comes back later. But I think that is ok.
Perhaps the timeout should be configurable, because it may be application specific. The app author might decide that users may switching from one page, and come back, usually within 5 minutes, after some user testing and stats tracking. Then the timeout can be adjusted to 7 minutes, to give time padding, just in case, for example.
Is there not already such options?
Why is the title marked with (Closed)?
I’m with you: The programmer decides where the data will last and for how long
I very much agree
Even the programmer must be able to decide if the data is a root without a time limit.
Atleast now you can decide by organazing your react components.
Because the OP has found a solution.
I think there should be a better solution.
For example, adding a feature to subscriptions to adjust data retention
Should open a feature request here: GitHub - meteor/react-packages: Meteor packages for a great React developer experience
Or maybe we can just ping @captainn here since we already wrote here.
Keeping useTracker inside a component, and not lifting it to a root component for longevity, is beneficial in order to keep functionality encapsulated and decoupled(f.e. the higher component cares not what each route individually needs to load with useTracker). So an expiration time option would be beneficial.
Hi, I see in this conversation terms like “expiration time” and “data retention”. I would like to ask what is this about? Expiration time of what exactly?
Yes, 100% of this feature is practical, but an optimal solution is needed.
We think that the subscription will not expire immediately after changing the route or changing the components, and will remain on the client for a while or forever.
Two cases are considered.
One, a set of data does not expire at all, that is, it is not deleted from the client and browser after route changing or unmounting component.
Two, a group of data after the unmount component, do not expire immediately, but expire after a certain period of time.
Why?
For example,
if the user is in the main route and takes the data and views it and goes to the next route.
If it returns to the main root twice, it will have to wait a while for the data to load.
In fact, previously shared (in main route) data must be retrieved from the server.
And this hurts the user experience.
But there is a problem:
If all app data remains on the client, the client may be corrupted due to the heavy volume of data.
So the functionality, the expiration of the data must be controlled.
For example, when subscribing, we have the option to specify what the data expiration will be
And be in two modes:
What you think?
I feel this can never be part of serious and maintainable data management.
This question is about React so I will write based on my React perspective/experience.
In React, standard is to use a data manger (like Redux) or a React Container that wraps around a … sorry for the repetition, a wrapper component from which you diseminate props (data and actions/functions) down the line.
The tracker used as effect in a component is … TODO app, the most basic example of getting data.
Where a lot of data changes in child components, React Memo comes handy to conditionally limit the UI/DOM changes.
In Redux it is very easy to add to your payload a lastPull date and depend on that to empty your Redux store or part of the Redux store.
However these things have nothing to do with modifying the subscriptions/publications or how the Meteor serves data.