-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
issue #1748 - Custom elements light dom, open / closed #4330
Conversation
Removed the WIP as I've added some tests and manually tried this out. Adding slots to lightdom web components is probably worth doing as a separate PR as this feature is pretty useful as is. Not sure how useful the closed option is, but it's at least complete that way. This doesn't break, only adds to the api. Could add to the docs too if that helps. Welcome any feedback. Also thanks to @fsodano for starting this off. Wasn't sure how to add to his PR so opened this one instead. |
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
any clue wy this great addition is not merged yet? |
@vospascal I wrote a wrapper to help with this - https://github.com/crisward/svelte-tag which may help as a stop gap. It has simulated slots for light dom too. |
@crisward yea i saw that thnx, but would be nicer to have that fixed in svelte ;-) |
I love everything about Svelte & SvelteKit but this restriction on custom element always using shadow dom. In order to build the large system i am designing, and pushing Svelte as the preferred choice for web components, it has to allow global inheritance of styles. Why is it taking so long to get this option? what is the issue? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks Good
Would be awesome to see more support on this important topic (in my opinion atleast). To use Svelte/SvelteKit components in a framework agnostic manner I do not see any other (effective) way than the use of Custom Components (Webcomponents). But since Shadow DOM limits the feature set of those components the developer should have the choice of the output target (here light DOM and open Shadow DOM). Since there is so much discussion going on (since about 4 years now) there should be viable options or atleast very good reasons against implementing those changes... love Svelte but this aint fun :/ I know @Rich-Harris has his concerns about this (and I agree with many statements) but there seem to be other reasons that block progress on this topic that I do not find. May someone help me understand? Are there other possible ways to build a highly reactive framework agnostic UI library with Svelte or SvelteKit (e.g. output: package)? |
Echoing what I said on #1748:
As an extra note here: FWIW, it appears that |
This is an overhaul of custom elements in Svelte. Instead of compiling to a custom element class, the Svelte component class is mostly preserved as-is. Instead a wrapper is introduced which wraps a Svelte component constructor and returns a HTML element constructor. This has a couple of advantages: - component can be used both as a custom element as well as a regular component. This allows creating one wrapper custom element and using regular Svelte components inside. Fixes #3594, fixes #3128, fixes #4274, fixes #5486, fixes #3422, fixes #2969, helps with sveltejs/kit#4502 - all components are compiled with injected styles (inlined through Javascript), fixes #4274 - the wrapper instantiates the component in `connectedCallback` and disconnects it in `disconnectedCallback` (but only after one tick, because this could be a element move). Mount/destroy works as expected inside, fixes #5989, fixes #8191 - the wrapper forwards `addEventListener` calls to `component.$on`, which allows to listen to custom events, fixes #3119, closes #4142 - some things are hard to auto-configure, like attribute hyphen preferences or whether or not setting a property should reflect back to the attribute. This is why `<svelte:options customElement={..}>` can also take an object to modify such aspects. This option allows to specify whether setting a prop should be reflected back to the attribute (default `false`), what to use when converting the property to the attribute value and vice versa (through `type`, default `String`, or when `export let prop = false` then `Boolean`), and what the corresponding attribute for the property is (`attribute`, default lowercased prop name). These options are heavily inspired by lit: https://lit.dev/docs/components/properties. Closes #7638, fixes #5705 - adds a `shadowdom` option to control whether or not encapsulate the custom element. Closes #4330, closes #1748 Breaking changes: - Wrapped Svelte component now stays as a regular Svelte component (invokeing it like before with `new Component({ target: ..})` won't create a custom element). Its custom element constructor is now a static property named `element` on the class (`Component.element`) and should be regularly invoked through setting it in the html. - The timing of mount/destroy/update is different. Mount/destroy/updating a prop all happen after a tick, so `shadowRoot.innerHTML` won't immediately reflect the change (Lit does this too). If you rely on it, you need to await a promise
Closed via #8457, to be released in Svelte 4 |
p.s. on @crisward's last point above on the light DOM:
After some work, I'd be interested in hearing whatever feedback you might have if any of you happen to have a chance to try it out. |
This is based on the pull request #4073 and issue #1748
The idea is to allow web components to render to light dom. As this may be something you don't want to do for all components within an app the option is included as part of the svelte:options tag.
For completeness I've also included
The main reason I have for needing light dom is to be able to create forms which auto-complete correctly as this currently doesn't work with shadow dom in chrome and safari. Though there are open tickets for this with the browsers. (eg https://bugs.chromium.org/p/chromium/issues/detail?id=746593)
If the tag is set to
shadowdom="none"
the css is processed as though it's a svelte element with the class addition and hashes, which gives some level of encapsulation even with light dom.Outstanding on this is slots. Not sure how these can be handled with light dom as Sveltes html is being appended to the innerHTML of the tag, as opposed to transposing the existing html into the slot. Lit-element just says if you don't use shadowdom you can't have slots or encapsulated css - (https://lit-element.polymer-project.org/guide/templates#renderroot). As svelte already simulate slots, it'd be nice to get this to work. Any pointers would be gladly received.