Custom element dispatch event #4142
Conversation
|
Any comments on this? |
|
@hontas Svelte generally tries to be very conservative when it comes to adding any bytes to that would need to be shipped to the client-side – especially if those extra bytes only benefit the red-headed stepchild of the browser that is custom elements. I think the target for fixing this issue would be for the I'm not sure what that change looks like when it comes to these |
|
I don't think we really have a good mechanism for varying what you get from the runtime The simplest solution of course would be something like this, where we ship extra bytes to everyone. This might not be so awful, as it would be per-app bytes, not per-component bytes. I'm not sure which I prefer. If we merge this PR though, that is a decision it would be hard to walk back. |
|
Sorry for the late response. Yet another option is to have warnings when compiling to custom elements so that it's clear what works and not. |
|
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. |
|
+1 for this. Svelte offers to export components as custom elements, the input properties are correctly mapped to the properties of the custom element, and yet its output events are not exported. This input/output asymmetry appears like a bug. Users expect the custom element interface to "just work". Svelte is an attractive framework for building component libraries and micro-frontend entry points due to its low overhead. But this issue is almost a blocker for adoption of the library in these scenario. |
|
IMO this tiny per-application overhead is worth it given how the current behavior clashes with users expectations. It would make sense for Svelte 3.x to accept regressions in code size at the benefit of better "out of the box" functionality. You could be looking at the crazy optimizations above for v4 because it seems like this would break a lot of internal APIs anyways. |
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 |
Possible solution to #3712, #3119 and #2611.
Enables event dispatching for custom elements. As it is now, no events are dispatched from a custom element because
component.$$.callbacks[type]is always falsy.When compile target is custom element, always dispatch event.
Atm checking this by
component.shadowRoot- perhaps there is a safer/better way?