What is import of html file?

[miksdigital]

Hello everyone!

What is import of html file need for?

It is like file inclusion?
Why it is in js file then?

import { Template } from 'meteor/templating';
 
import './body.html';
 
Template.body.helpers({
  tasks: [
    { text: 'This is task 1' },
    { text: 'This is task 2' },
    { text: 'This is task 3' },
  ],
});

Look here (official tutorial):

https://www.meteor.com/tutorials/blaze/templates

[gadicc]

It’s a load order thing. This way no matter what this JS file is called, you know that Template.body will exist before you use it.

[jaypanares]

I think what he meant was why we are importing the .html file inside the .js file:
import './body.html';

[gadicc]

That’s what I answered, but I guess not very well

This shouldn’t be confused with imports in certain config files which basically get substituted with their contents. i.e., in the example above, no HTML is being “imported” to inside the JS file.

The full import lines are clearer: import { Template } from 'meteor/templating'. That’s saying, meteor/templating should run before this file, and whatever it exports, put into my local Template variable.

The shorter line import './body.html' doesn’t make use of any exports (since Blaze/Spacebars stores all compiled templates under the Template object, which we already imported above), however, we’re still saying main.html must be evaluated before the current file, and hence, that Template.body will exist on the Template object, before the current file is run.

Obviously this isn’t strictly required because of the backwards compatible load order rules, but it’s a good practice moving forward (same as with all the import statements in general), it’s also makes it much clearer that this code wouldn’t work properly if it ran after main.html.

I hope this explanation was clearer but please let us know if not and hopefully someone else can do better

[maartenbusstra]

I do see this as a nice opportunity for MDG to make Blaze more in-line with the new modules in terms of usage. Something like:

import body from './body.html';
 
body.helpers({
  tasks: [
    { text: 'This is task 1' },
    { text: 'This is task 2' },
    { text: 'This is task 3' },
  ],
});

Note: THIS CODE DOES NOT WORK AT THIS MOMENT

[gadicc]

@maartenbusstra

I do see this as a nice opportunity for MDG to make Blaze more in-line with the new modules in terms of usage.

@nathantreid is on this:

Introducing Blaze "modules": locally scoped Blaze templates

When building larger apps with Blaze, I’ve regularly run into one of the problems of global scope: unique names. For example, I might have to 2 templates that would make sense to be named "asset’; one goes in the admin panel, the other in the main user view (we’ll call it the Asset Library)… Before today, I’d name them something like admin_assetLibrary_asset and assetLibrary_asset. I personally find this to be a pain, especially as the components get deeper. With 1.3 coming out I had hopes for…

[nathantreid]

Note that my Blaze Modules package as mentioned by @gadicc doesn’t handle the use case you presented since the “body” template is a “special” global template.
Perhaps I should consider making it (and all other global templates) non-default exports, so you could do:

import { body } from './body.html'; `

[gadicc]

Yeah actually that’s nicer, since the user might have multiple components per file, too. It’s clearer and forces the user to exactly match the component name.

[jaypanares]

Cool, cool