Open dherman opened 9 years ago
+1 for this feature. Is my understanding correct when I say that without this feature, the import
keyword could never refer to a custom loader, but instead would always refer to %BrowserLoader%?
@joeldenning that is correct. Without the ability to set System.loader
to a new loader instance, we have only two choices:
System.loader
's hooks to control System.loader.import()
calls.System.loader.import()
.@dherman Could you help me understand your second bullet point? I'm pretty new to reading through these types of specs and don't understand what you meant by "HTML semantics triggering a property get."
@joeldenning this is a question of whether <script type="module">
will have rely on a mutable System.loader
or not, and what are the implications of that from the security point of view since the engine will have to access something from user-land. Essentially, how the semantics of the script tag type=module will trigger a property get on System
to access the loader instance that should be used. If System.loader
can't be mutated, the engine can resolve this by keeping in internal slot for the default loader and there is not need to trigger a property get.
note: I don't think there is precedent for the property get triggered by HTML semantics, but I might be wrong.
Yeah, this is an area fraught with danger, as custom elements shows. But it should be possible to make this as palatable as custom elements, e.g. by deferring all such property gets until a later queued task, instead of having them happen during parsing.
Would document.cookie
be a precedent? It is a userland-writable property that the engine already has to look up whenever it sees a <script>
tag in the dom. For example, consider the following code:
document.cookie = 'joel=denning; ' + document.cookie
var el = document.createElement('script')
el.setAttribute('src', 'source-file.js')
document.body.appendChild(el);
I just verified in Chrome that joel=denning
is indeed sent as part of the cookie in the HTTP request.
ha, that is a good example. thanks @joeldenning.
In regards to the first bullet point in @dherman's original post, is there any feature there that could not be implemented in userland (especially now that, as of #65, a loader's registry is iterable)?
In other words, is there any advantage to having the host environment do "loader chaining" instead of userland code?
@joeldenning the question here is how <script type="module">
can rely on a custom loader vs custom hooks. If what you have in mind is to completely drop the support for <script type="module">
in favor of imperative code in userland, that will imply that you will have to have at least one "legacy" <script>
tag to invoke the loader, that's the part we are trying to mitigate.
To support not only subclassability (see #35) but the ability to use a custom subclass as the built-in loader, should we allow
System.loader
(according to the discussion in #34 this seems to be the best name for the default system loader to live in) to be mutated?The reason to allow this is that it's more expressive: if you have custom loader logic defined in a subclass, you can't use that simply by modifying the hooks of
System.loader
; you need to replace it with an instance of that subclass.There are a couple of subtleties, however:
System.loader
would require you also to populate the new loader's registry with any entries you want to share from the old one. (At a minimum this can be done by iterating over the old registry (see #17) and copying the entries in. Alternatively it should be possible to define subclasses with "chaining" logic that allows some lookups to delegate to another loader.)System.loader
being a getter/setter pair.