You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As ES6 modules going to have a way to define a module using
<script> or tag, such JS modules in an import should be able to
imported from another module in linking document.
import_a.html
import_b.html
import _ from "a"; // This should work.
To make this possible, ES6 loader should aware of HTML Imports and
HTML Imports should publish readiness to its possible clients somehow.
One idea is to let these two standards share some commonplace where the dependency management coordination happens. Such a place could be HTML, fetch, or somewhere else.
---
comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24848#c1
_johnjbarton_ wrote on 2014-02-28 01:54:02 +0000.
It's not clear that ES6 will even allow
in normal HTML. So far their model is that modules are in files or they are anonymous and not importable.
Within an import,
import "oof" from './oof';
may need some work on name normalization if the meaning is for the module 'oof' to be relative to the HTML import rather than the baseURL of the host document.
---
comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24848#c2
_Morrita Hajime_ wrote on 2014-02-28 02:13:40 +0000.
(In reply to johnjbarton from comment #1)
> It's not clear that ES6 will even allow
>
> in normal HTML. So far their model is that modules are in files or they are
> anonymous and not importable.
>
> Within an import,
> import "oof" from './oof';
> may need some work on name normalization if the meaning is for the module
> 'oof' to be relative to the HTML import rather than the baseURL of the host
> document.
Ah right. There is no way to define module name in plain ES6 module syntax
so + ES6 loader for browser or HTML imports need to define the mapping
of module names somehow.
---
comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24848#c3
_Dave Herman_ wrote on 2014-02-28 19:14:23 +0000.
Just to be clear:
- is an HTML construct and out of scope for ES6.
- Instead, (as well as the browser's default `System` loader) needs to be spec'ed as a web spec.
- The touch points for ES6 modules and HTML imports include at least the following requirements:
- HTML imports should be able to register ES modules in the system registry.
- While HTML imports want to be as concurrent as possible, the interaction with modules should avoid unnecessary races between multiple imports or imports and the main document deciding where to fetch modules' source from (since they can appear in ).
Dave
---
comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24848#c4
_johnjbarton_ wrote on 2014-02-28 22:06:15 +0000.
## I think the normal solution here is like:
Base.js:
class Base ...
import_a.html:
import {Base} from './Base'; ....
Derived.js:
import {Base} from './Base';
class Derived extends Base { ...
import_b.html
## import {Derived} from './Derived'; ....
That is, developers use anonymous modules for non-reusable JS related to their HTML, they use HTML-Import for re-usbable HTML, and they use JS-import for reusable JS.
The text was updated successfully, but these errors were encountered:
Title: [imports]: ES6 module loader should be aware modules in HTML Imports (bugzilla: 24848)
Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24848
comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24848#c0
Morrita Hajime wrote on 2014-02-28 01:41:06 +0000.
As ES6 modules going to have a way to define a module using
<script> or tag, such JS modules in an import should be able to imported from another module in linking document. import_a.html import_b.html import _ from "a"; // This should work. To make this possible, ES6 loader should aware of HTML Imports and HTML Imports should publish readiness to its possible clients somehow. One idea is to let these two standards share some commonplace where the dependency management coordination happens. Such a place could be HTML, fetch, or somewhere else. --- comment: 1 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24848#c1 _johnjbarton_ wrote on 2014-02-28 01:54:02 +0000. It's not clear that ES6 will even allow in normal HTML. So far their model is that modules are in files or they are anonymous and not importable. Within an import, import "oof" from './oof'; may need some work on name normalization if the meaning is for the module 'oof' to be relative to the HTML import rather than the baseURL of the host document. --- comment: 2 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24848#c2 _Morrita Hajime_ wrote on 2014-02-28 02:13:40 +0000. (In reply to johnjbarton from comment #1) > It's not clear that ES6 will even allow > > in normal HTML. So far their model is that modules are in files or they are > anonymous and not importable. > > Within an import, > import "oof" from './oof'; > may need some work on name normalization if the meaning is for the module > 'oof' to be relative to the HTML import rather than the baseURL of the host > document. Ah right. There is no way to define module name in plain ES6 module syntax so + ES6 loader for browser or HTML imports need to define the mapping of module names somehow. --- comment: 3 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24848#c3 _Dave Herman_ wrote on 2014-02-28 19:14:23 +0000. Just to be clear: - is an HTML construct and out of scope for ES6. - Instead, (as well as the browser's default `System` loader) needs to be spec'ed as a web spec. - The touch points for ES6 modules and HTML imports include at least the following requirements: - HTML imports should be able to register ES modules in the system registry. - While HTML imports want to be as concurrent as possible, the interaction with modules should avoid unnecessary races between multiple imports or imports and the main document deciding where to fetch modules' source from (since they can appear in ). Dave --- comment: 4 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24848#c4 _johnjbarton_ wrote on 2014-02-28 22:06:15 +0000. ## I think the normal solution here is like: Base.js: class Base ... import_a.html: import {Base} from './Base'; .... Derived.js: import {Base} from './Base'; class Derived extends Base { ... import_b.html ## import {Derived} from './Derived'; .... That is, developers use anonymous modules for non-reusable JS related to their HTML, they use HTML-Import for re-usbable HTML, and they use JS-import for reusable JS.The text was updated successfully, but these errors were encountered: