I very much agree with the overall thesis of the post. Runes are just irksome in subtle ways.
One big point that the post misses, is that the Class escape hatch for runes is incompatible with constructor-set parameters.
Say you have a class that wraps a HTMLElement which you set in the constructor. This doesn't work:
class Wrapper {
dom: HTMLElement = $state()
constructor(el: HTMLElement) {
this.dom = el
}
}
as TypeScript throws an error about `Type 'undefined' is not assignable to type 'HTMLElement' for the $state()`. You could fix it by eg. `$state(undefined as unknown as HTMLElement)` but that's dumb. Interesting enough you could do something like:
class Wrapper {
dom: HTMLElement
constructor(el: HTMLElement) {
let d = $state(el)
this.dom = d
}
}
Moreover, Vite/esbuild mangles class-field parameters with esnext into constructor-set parameters as they are just more versatile. So the original code becomes something like:
class Wrapper {
constructor(el: HTMLElement) {
this.dom = $state(el)
}
}
Which is incompatible with rules of runes. I did whine about this already
https://github.com/sveltejs/svelte/issues/14600 but so far no clear answer
One big point that the post misses, is that the Class escape hatch for runes is incompatible with constructor-set parameters.
Say you have a class that wraps a HTMLElement which you set in the constructor. This doesn't work:
as TypeScript throws an error about `Type 'undefined' is not assignable to type 'HTMLElement' for the $state()`. You could fix it by eg. `$state(undefined as unknown as HTMLElement)` but that's dumb. Interesting enough you could do something like: Moreover, Vite/esbuild mangles class-field parameters with esnext into constructor-set parameters as they are just more versatile. So the original code becomes something like: Which is incompatible with rules of runes. I did whine about this already https://github.com/sveltejs/svelte/issues/14600 but so far no clear answer