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.

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

Additional module types #4321

Closed
Jamesernator opened this issue Jan 25, 2019 · 2 comments
Closed

Additional module types #4321

Jamesernator opened this issue Jan 25, 2019 · 2 comments
Labels
addition/proposal New features or enhancements topic: script

Comments

@Jamesernator
Copy link

This is a followup to the issue on JSON modules (#4315) particularly regarding this comment.

This is just a list of common formats along with some suggestions and examples as to how they could be interpreted and used:

CSS (text/css)

The most logical thing to do when seeing a CSS response would be to construct a constructible stylesheet from it.

This would be useful in the Webcomponents set of technologies for including additional stylesheets on a shadow root without manually downloading and instantiating them:

import styles from './MyElement.css'
import template from './MyElement.html'

class MyElement extends HTMLElement {
  constructor() {
    super()
    this._shadowRoot = this.attachShadow({ mode: 'closed' })
    this._shadowRoot.adoptedStyleSheets = [styles]
    this._shadowRoot.appendChild(template.content.cloneNode(true))
  }
}

Plain Text (text/plain)

This would be useful for loading config files and such that aren't in JSON. However I'm a bit cautious about this one because it might encourage sending arbitrarily files as text/plain even when they have a more narrow type they could be. It might be better to have a special protocol for loading any resource as text (e.g. import config from 'text:./some-file.yaml') so that even if the MIME type is something other than text/plain it is interpreted as a plain text file.

Example:

import configText from './config.yaml'
import yaml from 'yaml'

const config = yaml.load(configText) 

Binary Data (application/octet-stream)

Similar to plain text, it might be desirable to load binary data for further use. However it suffers the same issue that we might want to load binary data from any MIME type, not just application/octet-stream so we can perform our own processing on it.

import historicalSamples from './historicalSamples.bin'

class HistoricalData extends HTMLElement {
  constructor() {
    super()
    this._plotData(historicalSamples)
  }
}

Media (image/*, video/*, audio/*)

I'm not sure these are worth including as the reasons for importing them are likely to be varied, for example for audio, would consumers want an element they can clone? An AudioBuffer for use in web audio? etc. I think settling on what the best thing to give them might be difficult. But it's at least worth considering.

XML (application/xml)

XML is still occasionally used for configuration so exporting an XMLDocument might be useful. Overall I'm not sure how widely used this would be to justify it.

import graph from './network.graphml' // An XML format for graphs
import d3 from 'd3'

class GraphDemo extends HTMLElement {
  constructor() {
    super()
    this._displayGraph(graph)
  }
}

EventSource (text/event-stream)

This could be useful for if multiple modules want to subscribe to a single source of events, e.g.:

import stockChanges from '/api/stockChanges'

class PriceGraph extends HTMLElement {
  constructor() {
    // ...
    stockChanges.on('message', message => this._appendData(message))
  }
}
// Same EventSource as the other file
import stockChanges from '/api/stockChanges'

class AverageOverLastTenMinutes extends HTMLElement {
  constructor() {
    // ...
    stockChanges.on('message', message => this._updateAverage(message))
  }
}

Overall conclusions

Overall I'm not sure how much value would be gained from adding import-ability for all the common MIME types used on the web even if a lot of them save a bit of repetition for things like new Image(new URL('./foo.png', import.meta.url)) or new EventSource('/api/currentlyWatching').

I think the main one of interest is CSS as it's likely to see a lot of use alongside the already proposed HTML modules in the context of webcomponents.

I think it's probably worth looking at other types though to investigate if there are any strong use cases that would justify import-ing them frequently.

@hinell
Copy link

hinell commented Jul 3, 2019

There is highly related issue opened in the w3c repo: WICG/webcomponents/issues/759

@annevk annevk added addition/proposal New features or enhancements topic: script labels Jul 3, 2019
domenic pushed a commit that referenced this issue Jul 14, 2021
This change extends the JavaScript module system integration to include CSS module scripts, in addition to JavaScript module scripts. These allow web developers to load CSS into a component definition in a manner that interacts seamlessly with other module script types.

Explainer document: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md

Closes WICG/webcomponents#759. Part of #4321.

This change includes the integration for the import assertions proposal (https://github.com/tc39/proposal-import-assertions/), thus closing #5640 and closing #5883 by superseding it.
mfreed7 pushed a commit to mfreed7/html that referenced this issue Jun 3, 2022
This change extends the JavaScript module system integration to include CSS module scripts, in addition to JavaScript module scripts. These allow web developers to load CSS into a component definition in a manner that interacts seamlessly with other module script types.

Explainer document: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md

Closes WICG/webcomponents#759. Part of whatwg#4321.

This change includes the integration for the import assertions proposal (https://github.com/tc39/proposal-import-assertions/), thus closing whatwg#5640 and closing whatwg#5883 by superseding it.
@Jamesernator
Copy link
Author

Closing in favour of #9444 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements topic: script
Development

No branches or pull requests

3 participants