Generate custom elements

[Rich-Harris]

I'd thought of this as a 'one day' feature, since custom elements aren't universally supported and we already have svelte-custom-elements. But then I started building an Electron app (where custom elements are supported), and started building a UI kit for it (because the nearest thing I could find, photonkit, appears to be abandoned and pertains to an older version of Electron), and it's one of those cases where custom elements really would be quite nice.

svelte-custom-elements sort of works, but it's suboptimal because

• no true style encapsulation (elements aren't shielded from global styles, and you don't get the perf benefits of a local CSSOM)
• there's no light DOM — slotted content becomes part of the shadow DOM

So I think we should add one of the following:

compiled = svelte.compile({
  customelement: true,
  name: 'x-foo'
});

compiled = svelte.compile({
  customelement: 'x-foo'
});

Maybe a component should be able to specify its own name, and customelement: true means 'use the component's self-declared name, or error if it doesn't have one', and customelement: 'x-foo' means 'register this component is <x-foo> whatever it calls itself'.

Differences in input/output that I can think of:

• it would export a class, rather than a constructor function
• styles wouldn't get transformed. (Not entirely sure how styles work tbh — does the <style> tag need to get attached to every single instance's shadow DOM?)
• <slot> elements would get rendered, and options.slots would be ignored (because there would be no options)
• attributes/props need to be part of the component definition (or compiler options, I guess, for situations where the component author didn't anticipate custom element usage)
• fire might need to wrap dispatchEvent? Not sure if we'd want to merge on and addEventListener (i.e. mix DOM events together with component events). I think we might have to so that <my-thing on:myEvent='doSomething()'> works. I guess we'd just disable bubbling by default, so that things don't get too wacky

A few nice things that would come out of this:

• Custom elements would still be Svelte components, so you'd still be able to use set, get, observe
• Svelte components would be elements, so you'd be able to listen for DOM events, style them, add classes, use transitions etc without having to add wrapper elements
• Svelte apps would be able to compile the custom elements with shared: true so there'd be very little overhead
• Our components would be smaller (and probably faster) than Stencil's 😀

Any thoughts?

[m59peacemaker]

Are there implications for svelte component npm package developers? Will we distribute more bundles so that there is an es and cjs version of both the webcomponent and non-webcomponent versions?

[Rich-Harris]

Good q. Thinking out loud — we should probably have some templates and 'official' guidelines for distributable components, but basically what I envisage is something like this:

my-thing
|- package.json # { "main: index.js", "module: index.mjs" and "svelte: src/MyThing.html" }
|- src
   |- MyThing.html
|- index.js
|- index.mjs
|- custom-element.js
|- custom-element.mjs
|- rollup.config.js # generates index and custom-element

Then you could use it like so:

// as a standalone component in a non-Svelte app
import MyThing from 'my-thing';
new MyThing({...});

<!-- as a component in a Svelte app (deduplicates helpers etc) -->
<MyThing/>

<script>
  import MyThing from 'my-thing';
  export default {
    components: { MyThing }
  };
</script>

// as a standalone custom element in a non-Svelte app
import 'my-thing/custom-element.mjs'; // or .js
document.body.innerHTML = `<my-thing/>`;

<!-- as a custom element in a Svelte app -->
<my-thing/>

<script>
  import 'my-thing';
</script>

The last of those is probably the most confusing. Basically your app's build config would need to specify that some of your components needed to be compiled as custom elements:

// rollup.config.js
import svelte from 'rollup-plugin-svelte';

// as an alternative to having two separate instances of the plugin,
// the app could just do `import 'my-thing/custom-element.mjs';` —
// it would just mean missing out on the deduplication
export default {
  // ...
  plugins: [
    svelte({
      include: 'node_modules/**',
      customelement: true
    }),
    svelte({
      exclude: 'node_modules/**',
      customelement: false
    })
  ]
};

I think that covers all the bases. Basically it should 'just work' with that structure, with opt-in further optimisations for Svelte apps.

[m59peacemaker]

Directory structure dependent modules are pretty mean to my obsessive brain. The svelte component distribution model has been nice to me, since import Thing from 'Thing' automatically imports either src/Thing.html or build/Thing.js dependent upon context, so we don't have to expose some kind of tree where you can find the thing you're looking for. Since ES modules with tree shaking are favorable over needing to put your dist files in a certain place in the directory for publishing, could there be a way to use default and named exports instead of an import path?

// awkward since no value is needed, and there's no way to determine what to shake, right?
import { ThingWebComponent } from 'thing'

// Seems like this should work out
import { Thing } from 'thing' // regular component

import 'thing' // web component

[Rich-Harris]

That wouldn't really work, because the custom element could never get shaken out (because customElement.define is part of the component definition, and has side-effects). You'd always end up with a copy in your app even if you weren't using the custom element, and — worse — you'd need to define customElement in browsers that didn't already support it. Having it in a separate file is the only way.

[Rich-Harris]

Closing this as #811 has been merged, and Svelte 1.37 supports compiling to custom elements

[m59peacemaker]

Oh right. Fortunately, I just had an alternate idea I'm less opposed to.

Build to ./web-component/index.js

import 'thing/web-component'

I'll just think of ./web-component as another ./build directory. It's a good enough alternative to building files to the project root.