Search code examples
javascriptmeteoriron-routermeteor-blaze

Meteor Iron-Router accessing variables through [data] vs [params]


In developing advanced routing and nested templates/data contexts in a Meteor project, I am trying to differentiate between the data and params components of a route in Iron Router and their best uses.

The goal is to merely pass simple variables/parameters to the template. Which is better, to use params or data, and what are the major differences or advantages in such a context?

To me the biggest difference seems to be that data is available as a data context in the Blaze template, while to access params requires passing that variable to the template via an associated helper.

I personally don't like the idea of setting full data contexts (from db queries) in the router config, and would prefer to do that in helpers. So I feel like the easiest way to pass these parameters to the template is actually through the data object, saving the extra code having to be written.

However this seems to be against common practice, so I'm looking for anything I've missed as to why this would be the case.

An example using data:

Router.route('aRoute', {data: {var: "this var"}});

I can access in template "aRoute":

{{var}}

Versus Using params:

Router.route('aRoute', {params: {var: "this var"}});

I need to create a helper first:

myVar : function () {return Router.current().params.var};

Then I can access the object in the template "aRoute":

{{myVar}}

Do I have this right? Am I missing anything? If I'm not really using data of the router for data contexts (as commonly used), is this pattern appropriate?


Solution

  • This is bordering on opinion - the preferred pattern in i-r is to use data: to set the data context of the route. This allows the template to consume data in a very standard way including potentially not requiring helpers at all!

    When i-r provides the data context the template can behave just like it was nested in another template and provided with a data context - there's no difference. With the params approach the template now can only be used on a matching route.