Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

import: URL support #2002

Closed
guybedford opened this issue Aug 25, 2019 · 15 comments
Closed

import: URL support #2002

guybedford opened this issue Aug 25, 2019 · 15 comments

Comments

@guybedford
Copy link
Member

Whether SystemJS would support internal import: URLs is still uncertain, but if it does, it would likely be a if (url.startsWith('import:')) url = url.slice(7); sort of approach.

The spec issue tracking this is WICG/import-maps#149.
@justinfagnani
Copy link

This would help my team immensely. cc @usergenic

@guybedford
Copy link
Member Author

@justinfagnani note that the issue here on the spec is still unresolved at WICG/import-maps#149. The concern remains implementing something that won't necessarily be in the spec.

@joeldenning
Copy link
Collaborator

joeldenning commented Aug 27, 2019 •
edited

I think there are different options to implementing this, each with their own level of spec compliance.

  1. Only support import urls on initial load, but not for dynamic injection after initial load. This could support <script src="import:">, <link href="import:">, etc, but would use the window load event to look for those. No Mutation Observer would be used.
  2. Full blown Mutation Observer on everything in the DOM that looks for import: in any <script>, <link>, <img>, or other elements that can load things using the import: syntax.
  3. Partial Mutation Observer on only the <head> element that supports <script src="import:">, <link href="import:"> and other html elements. Only listening to the <head> element prevents the dom having to allocate memory to the mutation observer every time a framework updates elements inside of <body>
  4. Partial Mutation Observer on <head> element that only supports <script src="import:">, without support for <link href="import:"> or other imports.

@joeldenning
Copy link
Collaborator

joeldenning commented Aug 27, 2019 •
edited

Personally, I lean towards Option 1 since I think that that covers majority use case and does not have significant performance implications. I think that shooting for full spec compliance with a Mutation Observer on everything (Option 2) would introduce too much performance overhead for system.js to be a responsible choice in production systems.

@justinfagnani
Copy link

Option 1 would suit our needs as well. It would be great if we could think of an API that other code can use to resolve resources that are dynamically created, and have it not be specifically tied to SystemJS.

@guybedford
Copy link
Member Author

Note that the other way to tackle these use cases is to simply implement a import.meta.resolve() function that behaves synchronously.

Ideally we should implement this as an extra for experimentation since we don't yet have a spec for this (although many are in agreement that it should exist).

Node.js might actually even be able to be a first-mover on import.meta.resolve ahead of the browser as it needs it as well.

Code can then assume -

const stylesheetURL = import.meta.resolve('./asset.css');

The biggest question right now around import.meta.resolve remains whether it should be sync or async.

@justinfagnani
Copy link

That sounds useful, but we'd still want import: support for SystemJS-loaded resources like CSS.

@guybedford
Copy link
Member Author

@justinfagnani to understand the use case, are you referring to supporting eg -

<link rel="stylesheet" href="import:systemjs"></link>

where those templates are server rendered?

In the case of client rendering I think a import.meta.resolve is a good forwards-compatible workflow.

For server rendering, I can understand the use case though if that is what you are after.

@joeldenning
Copy link
Collaborator

joeldenning commented Aug 28, 2019 •
edited

resolve resources that are dynamically created, and have it not be specifically tied to SystemJS

In conversations with Guy, we have been leaning towards the following format for this:

<script type="systemjs-module" src="import:name-of-module"></script>

The systemjs-module still ties you to systemjs and is not spec-compliant. Similar to <script type="systemjs-importmap">

joeldenning added a commit that referenced this issue Sep 1, 2019
@joeldenning
Loading of script type=systemjs-module scripts. Resolves #2002.
53eaba6
@joeldenning joeldenning mentioned this issue Sep 1, 2019
Merged
@viT-1
Copy link

viT-1 commented Sep 2, 2019

It would be nice (for Vue/Angular templates) to include support of html-files (to do this without bundlers I had to use gulp-html-to-js),
because of plugin-text is not working.

@joeldenning
Copy link
Collaborator

@viT-1 could you help me understand what you mean by "support of html files"? Are you talking about being able to do <script type="systemjs-module" src="import:name-of-module"> inside of the root html file?

Or are you talking about SystemJS being able to load an html file as a module (see #1992)?

@guybedford
Copy link
Member Author

An initial implementation of import: URLs has landed in #2015.

@viT-1
Copy link

viT-1 commented Sep 3, 2019 •
edited

@joeldenning

@viT-1 could you help me understand what you mean by "support of html files"?
Or are you talking about SystemJS being able to load an html file as a module (see #1992)?

Yes, able to load html as a module by import templ from 'templ.html'.

@joeldenning
Copy link
Collaborator

@viT-1 you are in the wrong issue then. See #1992

@viT-1
Copy link

viT-1 commented Sep 3, 2019

@joeldenning Ok

@viT-1 viT-1 mentioned this issue Oct 29, 2019
Closed
@khangsfdc khangsfdc mentioned this issue Dec 18, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@justinfagnani @guybedford @joeldenning @viT-1