In the process of developing a web application, I am faced with the task of dynamically examining the collections (publications) of a DDP server. One challenge that has surfaced is that once a Meteor collection is created, it persists throughout the duration of the app:
foo = new Meteor.Collection("foo");
However, depending on user interactions within the application, there might arise situations where 'foo' is no longer relevant. This could lead to unnecessary storage of collections and ultimately result in excessive data being stored on the client side.
The situation is further complicated by the fact that the client does not have prior knowledge of which collections it will subscribe to. This gives rise to complications in setting up template helpers. Most examples demonstrate helpers returning results from a specific collection like this:
return foo.find();
Still trying to grasp the concept of how reactivity functions, my assumption is that if I were to reassign 'foo':
foo = new Meteor.Collection("bar");
...the above helper code would not automatically update to return contents of 'bar'.
Update: To shed light on why I'm posing this question amidst suggestions pointing towards employing a combination of subscriptions and a single collection, here's some context:
- The client application lacks foreknowledge of server publications
- Conversely, the server is unaware of specifics regarding the client app
- The dynamic exploration of publications by the application (stored in a 'root' collection) necessitates subscription initiation
- I make use of DDP.connect to establish a connection to our dedicated DDP server alongside the Meteor server
The nature of the application in development resembles a PHP/Django admin interface tailored for our platform (cortex).
While one plausible strategy involves integrating functionality into the server that exposes the entire database through a singular publication, utilizing subscription parameters to filter the desired collection(s), handling subscription modifications poses challenges. Unsubscribing fails to clear the client-side minimongo collection, thereby retaining residual data from prior subscriptions. Consequently, the responsibility falls on the client to remove data between subscription switches:
foo_sub.stop();
foo.remove({});
bar_sub = remote.subscribe('bar'); // Assuming 'bar' publishes in 'foo'