Added ability to name anonymous modules #343
Conversation
|
Thanks! This is on the right track, but unfortunately not the exact spec behaviour. As such we can't take this. The spec behaviour will be I'm making it my top priority to do this transition at the moment. |
|
If there aren't other options for your use case, we could take this though assuming its going to be a breaking API change. I'd rather keep it undocumented as well. What do you mean it would make dynamic scripts specific to the page easily importable and reusable? |
|
How would I'm assuming that if we have something like: <script type="module" src="init-page.js">
export var foo = 'bar specific to page';
</script>We could do this elsewhere? import initPage from 'init-page';
console.log(initPage.foo);And of course: System.import('init-page').then(function (initPage) {
console.log(initPage.foo);
}); |
|
In my case, I'm wanting the above functionality but assumed the |
|
Also, the script would show up in the dev tools sources panel as |
|
The module system was changed a few months back to use URLs instead of special names. This was done to align with the rest of URLs instead of inventing all normalization operations. There's still the ability to perform pre-normalization steps like mapping Do you not have production issues with using inline modules? |
|
I might be doing something fundamentally wrong here, but suppose I have some pretty dynamic pages that initialize differently depending on the user, and I want to include these initialization parameters and methods immediately as inline script(s) rather than adding an unnecessary request. In the following (relatively simple) example, this HTML might be generated based on something the user created. <!DOCTYPE html>
<html>
<head>
<meta http-equiv='Content-type' content='text/html; charset=utf-8'>
<title>Example</title>
</head>
<body>
<div id="container"></div>
<script src="/js/system/system.js"></script>
<script src="/js/system/config.js"></script>
<script type="module" name="main">
import React from 'react';
import 'components/SomethingDynamic.css!css';
import App from 'components/SomethingDynamic.jsx!jsx';
var UserProps = {some: "json blob", generated: "by server"};
React.render(
React.createElement(App),
document.getElementById('container')
);
export { App, UserProps };
</script>
</body>
</html>And then suppose we had some other static module that could take a look at what exactly was created for the page via import main from 'main';
console.log(main.App);
console.log(main.UserProps); |
|
Unfortunately loading an ES6 transpiler in production is worse than an extra request here. The options are:
For production optimization you need to bundle though anyway, so I'm not sure that that extra request costs you anything at all. I'd strongly suggest the single main entry point bootstrapper approach. |
|
This page is actually generated in a development environment which is why I find it acceptable (and necessary). The production flow will definitely be different, minimal everything. |
|
I'll elaborate a little more. The idea here is that developers can collaboratively build apps in real-time, which is where this development page and all my other recent issues are coming from. :) |
|
don't forget that the |
|
This is conceptually happening at the spec level, and is consistent with our current spec model, so I'm happy to take it for now. |
Added ability to name anonymous modules
|
Sweet! @probins What's the best place to discuss the spec for this? |
|
Note the spec we're matching here is what was described in jorendorff/js-loaders#83 (comment). So we are being consistent with the previous intentions. There are NO guarantees though that this same behaviour will still even be possible in the updated spec though, so note that this is still at your own risk. If you want more certainty, I'd advise posting an issue at https://github.com/whatwg/loader as @probins mentions. |
|
Understandable. To me, the concept makes sense, plus the usage of a |
ghost
mentioned this pull request
|
@probins There is a module tag spec, though not active at the moment: https://github.com/dherman/module-tag |
|
yeah, thanks. I was actually aware of that (even have it in my bookmarks), but had forgotten :-) |
|
@timbur my apologies, but after the discussion on the loader project I've decided to remove this. Since it is now clear that this is not a feature that will be available, offering it now makes no sense. |
|
What makes no sense is excluding the feature. It's a one-liner that makes things flexible and hurts absolutely nothing. It will be ridiculous to have to include something resembling the following hack on every page where I want a common reference to a dynamic module imported during initialization: var modules = document.getElementsByTagName('module');
for (var i = 0; i < modules.length; i++) {
var module = modules[i];
if (module.hasAttribute('name')) {
var name = module.getAttribute('name');
var source = module.innerHTML.substr(1);
System.define(name, source);
}
}I'll wait patiently for someone to explain an alternative, equally elegant solution to the scenario I outlined here: whatwg/loader#42 (comment) |
|
if it's not in the spec, it probably won't be in browser implementations either, so you would have to come up with such a solution whenever that happens. Having it in the polyfill doesn't help you |
|
That's why I'm trying to get it in the spec. :) Check this nice little perk with named inline modules within dev tools (couple of screen caps to compare): whatwg/loader#42 (comment) |
When using
<script type="module">it would be nice to give it a name using something like<script type="module" name="init-page">so that it shows up as something other than<Anonymous Module 1>in dev tools sources panel. Plus it would make dynamic scripts specific to the page easily importable and reusable.