I inherited an app from a previous dev team and I’m new to Meteor and a lot of the stack, so bear with me.
I have a page where users can run a full text search to find doctors. The search works fine until the user navigates away from that page and comes back, after which the last search results that matched the search will be included in the next search. So if you do a search for “Aaron”, doctors matching that name will show up in the results, and if you leave the page and come back, “Aaron” doctors will show up in the next search, whatever that may be.
It seems the client-side cached search results are sticking around after the user navigates away from the page. Even when I explicitly clear the client-side collection out when I leave the page, the last values of the collection come back when I navigate to another page in the app and then come back. I’d love to hear anyone’s thoughts on what I might be doing wrong.
After grappling with this for a while I think I’m better able to explain what’s going on.
We have a publication that we use to fetch search results for doctors. We have client-side collection that holds the search results. When I leave the page where the search is done and come back, though, the last search results in the collection show up in the next search. It seems the client-side collection is not being cleared when leaving the page. Am I supposed to be doing something to clear the collection when the user navigates away from the page?
In general you should not rely on the client side collection being cleared at exact times or on not having any extra data. Especially in larger applications where multiple UI components (which probably will be developed at different times, maybe by different people) may subscribe to similar data concurrently, resulting in the client side collections having data that you really could not anticipate before.
Instead, you should rely on specifying Mongo’s find queries client side as well. In other words, you’d be running two queries at the same time. One on the server side in the publication (controls what data is pushed to the client), and the other client side in your local find (controls what data the client sees).
Since you’re dealing with a search feature, you’ll soon run into a similar problem trying to implement sorting. Sorting in the publication won’t really help. So there too you’d run the publication (without sorting) and then perform the sorting in the client side query.
Though, having said the above, for most search features I’d say it’s better to rely on methods instead of pub/sub since in most cases users will only look at the search results for a very brief moment. So there’s very little benefit in making the search results reactive. And it might even be detrimental - users usually don’t want the results list changing a millisecond before clicking on something. Methods consume much less server resources and you can easily control what data gets sent to the client (maybe you want to do some app level joins or data manipulation on the fly etc).
Thank you so much for your response. This was made more complicated because the publication uses a full-text search and minimongo doesn’t seem to support those, so there wasn’t a super clear way for me to simply query the client-side collection and be able to expect the same results.
What was ultimately happening was that the subscription wasn’t being stopped after the page changed, so leftover results from the original subscription were polluting the new results. I’m new to rxjs and I had to add takeuntil(this.unsubscribe$) to the end of the pipe function that gets the search results to make sure that this was cleared out when the page changes.
I’ll have to dig into methods a bit more. You bring up some good points there. Thank you for that suggestion, and thank you again for your help!