I’ve tried to tackle this multiple times over the past few weeks, and what in concept seems quite simple, is something I have struggled with every time. I haven’t yet come across a solution in these forums so posting this thread in the hope that someone can point me in the right direction (and hopefully help others in my situation because surely, this is a common scenario):
For reference, I am using React on the front-end, and getting reactive data via withTracker.
- I have a page that subscribes to some documents
- The user has an option to change a filter via a dropdown from ‘all’ to ‘sent’, ‘failed’ or ‘opened’.
- When the user changes the dropdown, this is sent to the server, which modifies the filter and query selector for the publication
- This works great for any new data coming down the wire, BUT, does not clear minimongo of old data that was present before a finer-grained filter was put in place.
#Question:
Is there a way to clear the minimongo cache?
Stuff that does not seem to have worked (unless I messed up the execution of it):
- The
.stop() function
- Calling a ._collection.remove({}) on minimongo (which causes all sorts of unpredictable results) - I think this is because in this case the server thinks certain documents have been sent when minimongo has removed them
- Stopping the subscription and starting a new one with different parameters
I hope the above scenario makes sense? Any help much appreciated!
Cheers
Currently it seems to me that you’re relying solely on the publication to select what the user sees on the page. In other words, it seems that you’re doing a Collection.find({query}) in the publication and then just doing a Collection.find({}) on the client inside React to display everything contained in Minimongo. If that’s the case, then I’d advise against that.
In most cases you should have two queries running side by side - one server side in the publication controlling what documents the user has access to and one client side controlling exactly what is displayed on the page. The former, of course, restricts the latter, but this should not be relied on directly for displaying the data. In general it is a good idea to assume that the local minimongo cache does contain data other than what you need currently (subscriptions from other components, previous routes, probably some caching related optimizations as well).
Here, if you want to have the ‘all’ be the default option and the data sets are of reasonable size, then in your publication publish the necessary data for ‘all’ and then when the user goes through ‘sent’, ‘failed’, ‘opened’ or ‘all’ just change the client side query to control what is displayed. That way you’re not hammering the server each time a user goes through the selections and, as an added bonus, the user does not have to wait for a response from the server to see the changes. If the data sets are large, then you’d need to publish based on the selection (as you have currently), but the client side query should then reflect the selection as well.
2 Likes
Hmm… I think I tried (and failed) a variation of this. But I’ll give it
another go based on your (great!) response.
Yes the number of documents is large - so I do have a limit (along with a
’load more’ button set up. But I think that should be manageable once I
have this figured out. I’ll post back here with updates (hopefully with a
success story) for others who may be on the same boat.
Cheers for that!
Right, some updates:
- I’ve added query selectors on all pages that are subscribing to the same collection, which seems to have helped with the flicker as minimongo update(s) documents as they come across from the server
- In terms of adding a filter and still maintaining a limit (along with a ‘load more’ button), it was proving a bit difficult (more below), - for the time being I have simply created different pages for the 3 different status types, each with its own separately named subscription. Probably not ideal performance wise, but is doing the job until I figure it out.
Issues with using the same subscription on the same page:
- I did it as a functional callback. So the ‘withTracker’ passes a function to the component, which when the params change, rerun the subscription. The issue with that being that the entire subscription was getting rerun when the loadmore button was pressed, so rather than loading the extra documents, it would rerender every document.
- Other than the rerendering, the loadMore button was not behaving predictably - clicking it would load more documents but the count was not the increase in number that was expected. I am sure this has something to do with the status types, but ultimately, as a time saving measure reverted to the work-around described above.
I’ll be back to update this if I learn a better way…