javascript - How to decide at runtime for which Meteor collection a client will subscribe -

i writing web application dynamically inspect collections (publications) of ddp server. 1 of issues i'm running once meteor collection created sticks around lifetime of app:

foo = new meteor.collection("foo"); 

however, depending on user application, might no longer interested in foo. wasteful have collection linger around, potentially end entire database being stored on client.

the issue made worse fact client doesn't know collections going subscribe for. think causes issues how template helpers setup. examples i've seen far show helpers returning results of particular collection, like:

return foo.find(); 

i still getting head around how reactive model works, i'm guessing if reassign foo:

foo = new meteor.collection("bar"); 

... above helper code not magically update return contents of 'bar'.

---

update: since suggestions revolve around using combination of subscriptions , single collection i'd thought give context why asking question:

1. my client app doesn't know in advance publications of server
2. the server doesn't know client app
3. the application has dynamically discover publications (these stored in 'root' collection app subscribe for)
4. i using ddp.connect connect our own ddp server in addition meteor server

the application i'm developing php/django admin, our own platform (cortex).

i add functionality server exposes entire database through single publication, , use subscription parameters determine collection(s) publication should forward.

this becomes bit of nightmare though when changing subscription. unsubscribe doesn't clear client minimongo collection, leaving residual data of previous subscription. client become responsible removing data in-between subscriptions:

foo_sub.stop(); foo.remove({}); bar_sub = remote.subscribe('bar'); // assuming 'bar' publishes in 'foo' 

i sure struggling bit terms.

as example can use meteorpad flowrouter , route based subscriptions.

http://meteorpad.com/pad/ba5dte94njfi3ztpa/playground_flow-router_chat

at least answer question quick:

1.) collection without subscribe (you have remove autopublish project) empty on client

2.) collection defines document structure

3.) depending on projects use number of collections, if have different document models (like tables in sql)

4.) should template or route based subscriptions - best not application wide.

5.) may subscribe additional arguments publish method, few documents requested , exchanged.

6.) may use col.find() on client, if example publish send out last 5 documents.

you should read meteorhacks subs-manager package, reduces number of data / collection exchange , speeds app.

you find online article sascha greif publish subscribe meteor.

i hope ressource guide right decisions.

have success tom

---

update:

you may have meteorpad see option write own publish method , push whatever content client. may depend on argument sended via submit.

http://meteorpad.com/pad/zq4qdmw84rkgersfh/sample_publish_to_local-collection_reactive_way

imagine not need return col.find() can use col.find() on server , update different documents.