feat: introduce $host rune, deprecate createEventDispatcher
#11059
Conversation
🦋 Changeset detectedLatest commit: 1456278 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| * | ||
| * https://svelte-5-preview.vercel.app/docs/runes#$host | ||
| */ | ||
| declare function $host<El extends HTMLElement = HTMLElement>(): El; |
There was a problem hiding this comment.
takes a generic because people could add their own properties to the element when using the extend feature of the customElement option and then want type-safety using it
| <button onclick={() => greet('hello')}>say hello</button> | ||
| ``` | ||
|
|
||
| > Only available inside custom element components, and only on the client-side |
There was a problem hiding this comment.
Only available within client-side custom element components.
There was a problem hiding this comment.
This raises an interesting question — what even is a server-side custom element component? What is supposed to get rendered? Should we be emitting declarative shadow DOM?
Are there any situations where $host() could be reached in a server environment? Instead of undefined, should it be a function call that throws a useful error (perhaps only in dev?)
There was a problem hiding this comment.
Calling $host() doesn't necessarily mean that you access one of its properties right away. You could save this to a variable. So an error could have false positives.
The question what we should be doing on the server is interesting indeed - I'm not even sure what would happen today if you do that. It's a larger/separate conversation IMO
There was a problem hiding this comment.
What about a proxy that threw on property access? That way if someone did something like
const parent = $host().parentNode;they would get a more useful error than Cannot read properties of undefined (reading 'parentNode') or whatever
There was a problem hiding this comment.
That could have unintended consequences in the case of checking if host is defined when writing code that is eagerly executed on the server
| <script> | ||
| - import { createEventDispatcher } from 'svelte'; | ||
| - const dispatch = createEventDispatcher(); | ||
| + let { onGreet } = $props(); |
There was a problem hiding this comment.
should we use lowercase names so it feels more consistent with DOM events? or is the inconsistency a feature rather than a bug?
| + let { onGreet } = $props(); | |
| + let { ongreet } = $props(); |
There was a problem hiding this comment.
I'd say feature - most people will likely separate the words somehow
There was a problem hiding this comment.
You know, thinking about this further, I think the idiomatic thing to do would be to pass in greet as a prop, rather than having a deeply weird distinction between DOM events and component 'events'. That also simplifies the code a fair bit — instead of refactoring the greet function defined here to call onGreet instead of dispatch('greet'), we can just remove it altogether.
The way to think of this is that you're not defining some behaviour that happens in response to a 'greet' event, you're defining what greet means
There was a problem hiding this comment.
I don't quite follow - are you suggesting to call it let { greet } = $props() (fine with me), or are you suggesting to remove the prop in this specific example (not fine, because this is about showing how to do events in Svelte 5)?
There was a problem hiding this comment.
Oh, yeah, I kind of like that idea. Props that begin with on don't have special behavior like attributes that begin with on do, so encouraging people to use that naming is probably confusing - not to mention this annoying question of how to capitalize it.
| - dispatch('greet'); | ||
| + onGreet?.(); |
There was a problem hiding this comment.
Shouldn't this be greet as well?
I have the feeling that this function either needs to be renamed, or can be removed from the example entirely (as greet seems to be given to the directly now)
There was a problem hiding this comment.
This is getting removed as part of this PR. We're no longer suggesting switching to onGreet.
There was a problem hiding this comment.
Oops, I got confused by the double diff syntax 😅
closes #11022
$host()returnsundefinedon the server, but it's not reflected in the types to not make interacting with it more cumbersome than it needs to be - I think that's an acceptable trade-off.Before submitting the PR, please make sure you do the following
feat:,fix:,chore:, ordocs:.Tests and linting
pnpm testand lint the project withpnpm lint