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.
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.
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!
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 ?
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.
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.
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.
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)
