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

compile to custom element #811

Merged
merged 11 commits into from
Sep 3, 2017
Merged

compile to custom element #811

merged 11 commits into from
Sep 3, 2017

Conversation

Rich-Harris
Copy link
Member

@Rich-Harris Rich-Harris commented Sep 2, 2017

Ref #797. Let's see how this goes...

  • Export a class that extends HTMLElement
  • Call customElement.define(tag, name)
  • Expose props
  • Guess props, if unspecified, based on data the template requires
  • Render <slot> elements
  • Render <style> elements, with untransformed CSS. (This part might get... interesting. Not 100% sure how shadow DOM scoping rules work)
  • Ensure generated classes can be instantiated with new, both in user code and with nested components
  • Figure out what the correct SSR behaviour is
  • Handle initial attributes and setAttribute

Currently, the API I'm building around is this:

// if the component exports a `tag` string and (optionally) `props` array
compiled = svelte.compile(source, {
  customElement: true
});

// if the component doesn't export those things, or you want to override
compiled = svelte.compile(source, {
  customElement: {
    tag: 'my-custom-element',
    props: ['foo', 'bar']
  }
});

Might make sense to also have something like this:

compiled = svelte.compile(source, {
  name: 'NavBar', // build tools typically generate this from filename
  customElement: {
    tag: 'my-[auto]' // becomes 'my-nav-bar', etc
  }
});

Here's where I've got to so far:

screen shot 2017-09-02 at 4 36 32 pm

@Rich-Harris
Copy link
Member Author

I think this is in a reasonably good place — I wouldn't call it production ready, but I think the best thing to do is to merge it in and start playing with it to see where the bugs are.

:global(...) styles aren't currently handled, so there's some work to do there as a follow-up. And I don't really have a good SSR plan.

Feedback on the API etc welcome.

@Rich-Harris Rich-Harris changed the title [WIP] compile to custom element compile to custom element Sep 3, 2017
@Rich-Harris Rich-Harris merged commit 7c29def into master Sep 3, 2017
@Rich-Harris Rich-Harris deleted the gh-797 branch September 3, 2017 14:07
@robdodson
Copy link

wow this is cool!

If it's any help, I've been working on custom element best practices docs and did a talk on them at Polymer Summit. All of this material is geared toward vanilla custom elements to (hopefully) make it easier to build abstractions on top of them. Happy to try to answer any questions that come up as you're working through this :)

@Rich-Harris
Copy link
Member Author

thanks @robdodson! will read this document carefully later — from skimming, it looks like there are some things we can enforce at compile time, some things we can warn on (e.g. :host { display: block } without respecting hidden etc), and other stuff that will have to be left to the component author. Very useful resource 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants