Enable locally-scoped, importable Blaze templates about blaze HOT 18 CLOSED

This is amazing. I would love to see this be moved to core Blaze, but I assigned this to the "Future ideas" milestone because I think we should first do some basic improvements to Blaze ecosystem to be able to easier get such improvements into Blaze.

from blaze.

Nice job @nathantreid! I would love the final implementation to have following features:

• import inside blaze files

<import template="component1" from="./component1.html">
<import template="component1" as="component2" from="./component1.html">

• keep template tag and add export attribute

<template name="component" export>
  ...
</template>

• export multiple templates

<!-- exported as default template -->
<template name="component1" export="default">
  ...
</template>

<!-- exported as component2 -->
<template name="component2" export>
  ...
</template>

<!-- exported as component -->
<template name="component3" export="component">
  ...
</template>

from blaze.

I would suggest that we make it simpler and simply keep template. So I would suggest (as proposed in #75) that we simply make that every .html package becomes a JavaScript module, and every template exports its template as a symbol with template name from that module. If you do not want to export, we can add (lower priority to me) something like <template name="Foo" private="true">. But default would be exporting (I do not see really arguments against that to be the default, but it would make boilerplate simpler).

Moreover, every exported template at that spot in the template module simply assigns it to module.exports object. So if you want to fine tune it, you can add a <script> tag at the end of your template module and modify module.exports further.

from blaze.

I think the only question is, do we still register templates into a global namespace? Because the issue is that they have to be unique there.

from blaze.

That's the reason why I went with a <component> tag - I also wanted to have exports / local by default, but also needed to keep compatibility with existing apps / "Meteor Classic". I definitely think we should be avoiding the global namespace, but I'm wary of making a change that will break all existing Blaze templates.

Moreover, every exported template at that spot in the template module simply assigns it to module.exports object. So if you want to fine tune it, you can add a <script> tag at the end of your template module and modify module.exports further.

This is great!

from blaze.

Yea, but I would prefer to make it compatible instead of introducing a new tag. I think it could be done with some help of Meteor migration. So we could make Blaze not export any templates by default.

And then we would have blaze-global-templates which would on the app scope export all templates defined there, and on package scope as a dependency export all templates of the package. And then Meteor migration would add it to app packages.

Moreover, using <script> you could simply register template globally as well in the new system. If you need one template to be global for some compatibility.

Alternatively, we could just bump major version and make it not compatible change and this is it. I also think we should not be too scared of doing incremental changes with clear upgrade paths and documentation.

from blaze.

One other thing could be also adding an option to addFiles which would make things global or not for all Blaze .html files inside that call.

Like:

api.addFiles([
  'foo.html'
], {exportGlobally: false});

I think this might even be the best option. And then we can have a deprecation warning for some time that default will be switched to false in few versions. I really like how Django is upgrading their code. Where for every backwards incompatible change they make a plan, and first introduce a warning, and then make a change. So if you would not have exportGlobally option at all (true or false) you would get a warning. And then we change default and remove a warning after few versions.

from blaze.

I think we do not need <import> tags if we have <script> tags.

One other change I would do is make {{> symbol}} resolve to a variable symbol and not string "symbol". So then the question is just how you get that symbol into a template, which could be using script, using a helper, or whatever. And there could be a global helper for importing a template. Like

{{> (import './foo.html' 'Bar')}}

from blaze.

One other change I would do is make {{> symbol}} resolve to a variable symbol and not string "symbol".

This already works in Blaze today; if you pass in the template symbol via a helper, it will display the template.

from blaze.

This already works in Blaze today; if you pass in the template symbol via a helper, it will display the template.

Yea, but if it is not a helper, then it is used as a string and tries to be resolved as a global template. Maybe that is a good transition mechanism, but maybe we should be stricter here. So if you want a global template, you should use {{> 'symbol'}}.

from blaze.

The blaze-global-templates package sounds good to me - breaking change, but providing a simple backwards compatible extra plugin.

api.addFiles([
  'foo.html'
], {exportGlobally: false});

I really dislike this because it only works inside of packages, and even then only works if you aren't just using api.mainModule.

from blaze.

@nathantreid I agree with you.

from blaze.

@mitar This breaks backwards compatibility, almost breaks all existing apps. I would prefer an <import>, like <import src='../xxx.html' as='whatever'>.

from blaze.

I really dislike this because it only works inside of packages,

We could use the above mentioned package

and even then only works if you aren't just using api.mainModule.

But isn't this perfect? If you are not doing addFiles, but just importing it, then you are not exporting it globally. It exports a template globally only if you do addFiles, and then you can configure it to not do so. No?

from blaze.

This breaks backwards compatibility, almost breaks all existing apps.

What exactly breaks all compatibility?

from blaze.

but maybe we should be stricter here. So if you want a global template, you should use {{> 'symbol'}}.

Maybe I misunderstood something?

from blaze.

Just tried blaze-modules, looks just amazing! Very elegant and understandable solution. Considering Meteor 1.5 is about lazy loading, thumbs up to include this into any of upcoming versions of Blaze.

from blaze.

I'm closing this issue because it's too old.

If you think this issue is still relevant please open a new one.

Why? We need to pay attention to all the open items so we should keep opened only items where people are involved.

from blaze.