Router.current().data() vs. Collection.find()?

I’m still learning Meteor & Iron Router, but I’m a little confused about the multitude of ways to access data. I’ve got a (seemingly) straightforward app with a client subscription to a Collection, routed with Iron Router.

But am I supposed to use Collection.find() in my client code or Router.current().data()? Does it matter?

I think Collection.find() would be the best practice. Router.current().data() works only with iron-router and simply returns all the data while the other one has the mongo api (search, filters, etc).

Collection.find() and Collection.findOne() are the only way to read data from a collection. The data() function from Iron Router allows to attach data (which you often get from Collection.find() anyway) to a route.

Some might disagree, but if you are learning Meteor, stay away from Iron Router. It is a complex package. If you really need a router, use only the most basic features of Iron Router (route declaration + Router.current().params to get the route URL reactively).

1 Like

Check out https://github.com/meteorhacks/flow-router. It is very minimal router.

I don’t think you simply can compare Collection.find (Collection.findOne) with Router.current().data(). The first one is usually used to set the data context the template should be rendered with, while the other one is used to retrieve the data context the template is rendered with.

I usually use Collection.findOne to set the data context the template should be rendered with, and use templateInstance.data to retrieve it in template functions.

1 Like

@delgermurun, thanks a lot for the link to the new routing package.

Maybe it could be even more minimalist, but it looks already like a huge progress over Iron Router (still have to try it, though).

I keep coming back to this question because it feels extremely unsatisfying that there’s no consensus on the approach. I thought the “Meteoric” way is ONLY to use Pub/Sub (the route returns a subscription, and the template uses Collection.find), and so never ‘manually’ pass a data context from a route.

Does anyone agree? What am I missing here?

I don’t think your question makes sense.
@Peppe_LG made this same point above…

Collection.find() on the client will allow you to search a subset of the mongo DB you have subscribed to.
This is the only real way to search your client side mongo data.
Router.current().data() is just a snapshot of whatever data you’ve associated with the current route. Which may or may not be collection data… it could just be some data you’ve set in your router. It might be a single document from your collection.

As I learn more and think through this, and especially as I’ve been trying out Flow-Router, it seems like the best practice (if there could be one) would be to have as little data context in the router as possible, and get ALL the rest of your data in the client as Collection.find(). Indeed, this seems to be the explicit philosophy of Flow-Router, as it is not reactive anyway.

Bingo. That’s not to say you can’t replicate the functionality of iron router by having your own ReactiveDict with a data context (for example, when a query param changes, do a Collection.findOne and store the result to the session var), but by keeping it out of the router layer you’ve got a lot more modular, predictable code.