Dot vs bracket notation on Templates, which, why?


#1

Whenever I want to work with a template

<template name="foo">
</template>

I define helpers/events/callbacks like

Template.foo.onCreated(function() {
  // do something
})

while I’ve recently begun seeing the form

Template['foo'].onCreated(function() {
  // do something
})

Now I usually try to avoid using the bracket notation unless that’s my only choice. TBH, this is mainly because the bracket notation breaks code assistance within the IDE environment (webstorm, netbeans, eclipse etc) and I vaguely remember something about the dot notation being more performant.

Now, the proposed official meteor guide articles are now using the bracket notation. While, the official tutorial and example apps use the dot notation.

Could someone explain what really the differences are and why one should prefer one over the other.

Ping @sashko :wink:


#2

I think, it depends on how you like to name your templates. So, if you use some kind of a package namespace, you can write it namespace.Name or namespaceName.

If you write it like in the first variant, you need to write it in Template['namespace.Name'].onCreated, with the second variant you write Template.namespaceName.onCreated.

There is an idea and an issue somewhere to make it possible to use Template.namespace.Name.onCreated.


#3

Yeah, but there also used to be discussions against the use of dots and
dashed in template names, in fact I think I remember such names throwing
exceptions!


#4

I’ve always used the camelCase names with no problems. Don’t know, why the dot / bracket things are recommended.


#5

Yep, me, too!. The thing is, now this new notation is creeping up in official documents so I want to check if I have not already become a dinosour :smile:


#6

Where do you see us using bracket notation in the guide? I’m definitely not into the brackets.


#7

With Typescript, you must use the bracket notation or the compiler complains that the property doesn’t exist on template.
Perhaps that with vanilla Js the intent of the author is to show that he is adding (registering) something on Template ?


#8

@sashko

I’m definitely not into the brackets.

Me, neither, nice to know! Here are the places I’ve spotted them:

@vjau

With Typescript, you must use the bracket notation

That’s news to me! Perhaps also a bummer since it kind of defeats typescript’s purpose, right?


#9

One of the multiple benefits of Typescript is to ensure that all the methods/members you are using/calling do indeed exist.
I you have a Foo object defined in the interface to have a bar member, if you try to write Foo.baz = 5 typescript will complain that Foo has no member “baz”.
Now the bracket notation is used to tell typescript that this object will be used as a dictionnary with an increasing number of properties and that you know what you are doing. So “Template” is one of the exceptions where you have to use the bracket notation to “add” arbitrary members that can’t be defined before in an interface.

I think Typescript type checking is a very useful addition to the language an i hope it will be standardized in vanilla JS circa ES8.


#10

The only difference in these notations is that you may use an extended character set (like dots) if you use the bracket notation. And you may pass in variables, so the ‘foo’ part might be dynamic as well (though I don’t see a concrete use-case for this in the case of Meteor templates). There are other use-cases, however, where this notation comes in handy, e.g. if you want to iterate over all keys in an object. In your examples, both notations are equivalent.


#11

That’s to allow the dashes in the names. I would prefer camel-case syntax in these cases, but that’s a matter of personal style.


#12

I agree with your comments in general, but the point is dashes and dots are special characters that have special meanings in resolving and evaluating spacebars inclusions and expressions.

Take a look at https://github.com/meteor/meteor/issues/1602 where @glasser himself says (about template names with dashes in them):

Probably the template should fail to compile…

The problem is, my-template and x-y are indistinguishable, so as my.template and deep.property therefore to allow the future of Blaze and spacebars that room, templates names with dashes and dots should throw errors, leacing the bracket notation only redundant, a choice of coding style (well, except for typescript devs)

So in terms of a style preference, Meteor already has a style guide that reads:

Functions should be named like doAThing, not do_a_thing.
Other variable names get the same treatment: isConnected, not is_connected.

I know this is not written especially for templates, but it is the closest thing.

So anyway, I guess now we have two questions:

  1. Do we get to use dashes and dots in template names?
  2. Do we prefer dash over dot notation?