Make dotted names work in the Meteor template compiler about guide

[stubailo]

This will almost certainly mean making it an error to assign helpers in the super old pre-1.0 way. But we've been warning about that for over a year now so it's probably OK.

[stubailo]

@mitar I see that Blaze Components already have this feature: https://github.com/peerlibrary/meteor-blaze-components#namespaces

Do you see any problems with adding this to core templates?

[mitar]

Hmm, if I remember correctly, there were quite some edge cases to cover.

First, probably it would be easiest to simply make templates be accessible under Template['a.b.c']. Uglier, but should just works.

Then the question becomes can Template.a also be at the same time another template or not. In Blaze Components it can. So namespace of namespaces is different from namespace of templates. Pretty useful.

Then some things should be fixed:

• meteor/meteor#4230
• meteor/meteor#4232
• peerlibrary/meteor-blaze-components#21

And Spacebars.dot has to be monkey-patched: https://github.com/peerlibrary/meteor-blaze-components/blob/master/lib.coffee#L35

So the hard problem is {{> a.b.c}}. That one has to be supported correctly. And potentially (not in Blaze Components) b could even be a helper returning a namespace.

So yea, it can be done, but I think some more work has to be done. Question is, should we all just move to Blaze Components instead. ;-)

[stubailo]

I don't feel like #4230 or #4232 are blockers for specifically this issue. They are all bugs related to dots and templates, but I'm not talking about rendering templates returned from helpers here. I'm planning to just add a thing that says "check a.b.c in its entirety against the space of available templates."

[raix]

Imho its an issue with Meteor templates namespacing / scoping in general - Theres no way for two packages to export ui components. (should be treated as symbols/js objects - this is something handled better in the react pattern, where you have more control + can extend components etc. more easily)

[mitar]

This is why I am proposing that templates are exported as whole names, so Template['a.b.c']. Then one package can export Template['a.b'] and another Template['a.d']. BTW, exporting various components from various packages of course works much better in Blaze Components which have a separate concept of a namespace. (So you can have both Template.a as a template and Template.a.b as a template.

[tmeasday]

I guess we are not going to do this in the end.

[mitar]

Why not?

[stubailo]

I could maybe take it if someone has a nice PR (I can't remember if there is or not) but it seems simpler to just make an exception for templates and namespace them with underscores rather than writing a bunch of code just to make the separators dots. Plus, underscores have the nice advantage over dots in JS that they don't need to be put in quotes and brackets when accessing a template.

[mitar]

One more reason to use Blaze Components then. ;-)

[stubailo]

Sure!

[raix]

We could just have "Template" be scoped to package or app.

import { Template as accountTemplate } from 'mdg:accounts-ui'

Template.main.helpers({
  logout: accountsTemplates.logout
});

or

  import { myTemplate } from './my-template.html'

  myTemplate.helpers({
    foo: () => 'bar'
  });

  export { myTemplate }

[stubailo]

Yes but all of that requires additional code to be written - namespacing via underscores doesn't.

[mitar]

So, we get again back to the question of how much time does MDG want to invest into improving the platform, or are we just stuck with what we have.

[mitar]

Like, the point of Meteor Development Group is to develop, no?

[stubailo]

I mean if you want to get technical then the word "develop" doesn't just mean writing code. We're investing literally all of our time improving the platform, we just don't currently think that spending a week making templates work via import/export is the highest priority right now.

[mitar]

And what is the priority? Still just Galax?

Maybe then guide should recommend Blaze Components? If you do not have time to invest to make bare Blaze improved, which is OK, then start promoting projects which do that? I thought the agreement was that because we can modify Blaze according to some ideas from Blaze Components, we can then cover common cases.

But maybe Blaze Components is the way what should be promoted in the guide:

• it fixes the issues of this in helper and event handlers
• it moves development to components, so conceptually it will be easier for people to later on move to React
• if makes things reusable
• provides namespaces
• solves many other small discrepancies
• it is much more performant than Blaze because it does not recompute everything on every data context change.