Static property access in abstract and subclasses results in errors | TypeScript Community | Page 1

ivory patrol Jul 25, 2023, 1:29 PM

#

Hi,

I was just playing around with some class-based syntax, and quickly ran into a number of different unexpected errors (even more if you've got a strict ESLint setup). Please see the attached code sample. There are a few attempts there commented out to remedy the situation but I didn't find them satisfying. There's also an open issue (from 2015!) https://github.com/Microsoft/TypeScript/issues/3841

Does anyone here have ideas around best practices for using static properties? I'd appreciate any help, especially as I find it difficult to believe that there are no straightforward solutions to these very basic use cases. Thanks! ✌️

GitHub

T.constructor should be of type T · Issue #3841 · microsoft/TypeScr...

Given class Example { } The current type of Example.constructor is Function, but I feel that it should be typeof Example instead. The use case for this is as follows: I'd like to reference the ...

honest barnBOT Jul 25, 2023, 1:29 PM

#

slashrug#0

Playground Link

Preview:```ts
export abstract class Renderer {
// declare ['constructor']: typeof Renderer

public constructor(protected readonly component: Component) {}
public abstract initialize(): void
}
// export interface Renderer {
// constructor: { [Prop in keyof typeof Renderer]: (typeof Renderer)[Prop] }
...```

dusk storm Jul 25, 2023, 1:44 PM

#

I'm not sure how common what you are asking for (static inheritance) is done in JS, but quite some OOP languages simply don't have it. C# for example existed without it for a decade and is only added recently.

honest barnBOT Jul 25, 2023, 1:50 PM

#

nonspicyburrito#0

Playground Link

Preview:```ts
abstract class Renderer {
public constructor(
protected readonly component: Component
) {}
public abstract initialize(): void
}

abstract class Component {
protected readonly renderer: Renderer

public constructor() {
this.renderer = this.createRenderer()
...```

dusk storm Jul 25, 2023, 1:51 PM

#

For example your Component code could be rewritten like this and eliminate the use of static completely.

ivory patrol Jul 25, 2023, 1:55 PM

#

dusk storm For example your `Component` code could be rewritten like this and eliminate the...

Well I'd like my Renderer associated with a component on a class level, not on an instance level. More importantly, although you've omitted this part, I definitely wouldn't want a copy of the exact same template string in each component instance.

dusk storm Jul 25, 2023, 1:57 PM

#

Instance methods and properties are on the prototype, they don't get a copy of everything on every instance if you are worried about memory usage.

ivory patrol Jul 25, 2023, 1:57 PM

#

dusk storm Instance methods and properties are on the prototype, they don't get a copy of e...

No, only methods are on the prototype, data properties are initialized for each instance.

dusk storm Jul 25, 2023, 1:58 PM

#

Not if you use a getter.

#

class Foo {
    private get template() {
        return 'the template'
    }
}

No instance of Foo will get a template property, it exists only on the prototype.

ivory patrol Jul 25, 2023, 2:00 PM

#

I appreciate the brainstorming but I'd like to know how to use a language feature, not how to avoid it. (I'm already considering not using class syntax at all to get around all the weirdness...)

dusk storm Jul 25, 2023, 2:01 PM

#

I'm just pointing out there are alternative ways to go about it, as seen in many other OOP languages where this isn't possible at all and they live just fine.

undone frost Jul 25, 2023, 2:40 PM

#

nice I didn't know declare ['constructor']: typeof MyComponent was possible

#

and I remembered why you shouldn't use typeof Class unless you're wanting the construct signature

honest barnBOT Jul 25, 2023, 2:45 PM

#

webstrand#0

Playground Link

Preview:```ts
class Foo {
declare ["constructor"]: typeof Foo
constructor(a: string) {}
}

class Bar extends Foo {
declare ["constructor"]: typeof Bar
constructor(b: number) {
super("")
}
}```

#

class Foo {
  declare ["constructor"]: typeof Foo;
  constructor(a: string) {}
}

class Bar extends Foo {
  declare ["constructor"]: typeof Bar;
//        ^^^^^^^^^^^^^^^
// Property '["constructor"]' in type 'Bar' is not assignable to the same property in base type 'Foo'.
//   Type 'typeof Bar' is not assignable to type 'typeof Foo'.
//     Types of construct signatures are incompatible.
//       Type 'new (b: number) => Bar' is not assignable to type 'new (a: string) => Foo'.
//         Types of parameters 'b' and 'a' are incompatible.
//           Type 'string' is not assignable to type 'number'.
  constructor(b: number) {super("")}
}```

undone frost Jul 25, 2023, 2:46 PM

#

or at least one of the reasons why this.constructor isn't typed by default

undone frost Jul 25, 2023, 2:50 PM

#

ivory patrol No, only methods are on the prototype, data properties are initialized for each ...

btw

class Foo {
    declare htmlTemplate: string;
    static { this.prototype.htmlTemplate = "<div>Hello World!</div>" }
}

is an alternative

#

that's what I do when I want constants on the prototype anyway

#

it's all consistently typed without needing "magic" to keep inheritance working

#

you just need a little magic to set the prototype in subclasses that need to modify it

ivory patrol Jul 25, 2023, 2:52 PM

#

honest barn ```ts class Foo { declare ["constructor"]: typeof Foo; constructor(a: string...

Yeah whatever I've tried from that Github thread had some issues.

undone frost Jul 25, 2023, 2:52 PM

#

declare ["constructor"] appears to be equivalent to declaration merging an interface and far less cumbersome

ivory patrol Jul 25, 2023, 2:52 PM

#

undone frost btw ```ts class Foo { declare htmlTemplate: string; static { this.protot...

That's really good actually, my idea was to define it on the prototype anyway (and do away with classes) but this might be better.

undone frost Jul 25, 2023, 2:53 PM

#

might want to use Object.defineProperty instead of = so that you can mark the property as non-enumerable

ivory patrol Jul 25, 2023, 2:53 PM

#

Yep.

undone frost Jul 25, 2023, 2:53 PM

#

it only ever happens once at runtime, so the cost is not terrible

#

finally, you can also set the htmlTemplate using a class decorator

ivory patrol Jul 25, 2023, 2:53 PM

#

That was my thought process, but you know at that point all the class sugar seems like unnecessary noise..

undone frost Jul 25, 2023, 2:54 PM

#

might be more ergonomic than using static { }? I'm not sure

undone frost Jul 25, 2023, 2:54 PM

#

ivory patrol That was my thought process, but you know at that point all the class sugar seem...

classes are non-optional in ES6+, you can't use traditional functional-based classes with them

#

super, #private, target.new, etc all break

#

it's no longer just sugar, sadly

ivory patrol Jul 25, 2023, 2:55 PM

#

I mean afaik #private and decorators don't mix anyway.

undone frost Jul 25, 2023, 2:56 PM

#

I mean like, in plain old javascript

class Foo {}
function Bar() {
    Foo.call(this);
}
Bar.prototype = Object.create(Foo.prototype);
new Bar();

you can't use ES6 classes with ES5 classes

#

it's a runtime error

#

so just get rid of the idea that the old prototype-style classes still exist. They do not, not really

ivory patrol Jul 25, 2023, 2:57 PM

#

Meh who needs constructors anyway

undone frost Jul 25, 2023, 2:57 PM

#

well, building objects dynamically and filling them with methods is much slower

#

Object.create is pretty slow, too last I measured it

ivory patrol Jul 25, 2023, 2:57 PM

#

Prototypical inheritance is all I need I mean.

undone frost Jul 25, 2023, 2:58 PM

#

delete Object.prototype.__proto__ is essential for security

ivory patrol Jul 25, 2023, 2:58 PM

#

undone frost Object.create is pretty slow, too last I measured it

Really? I know setPrototypeOf is slow, but I've seen no warning about Object.create

undone frost Jul 25, 2023, 2:58 PM

#

Object.setPrototypeOf is rather dangerous for performance

undone frost Jul 25, 2023, 2:58 PM

#

ivory patrol Really? I know setPrototypeOf is slow, but I've seen no warning about Object.cre...

it's substantially slower than making class instances

#

oh I keep forgetting, but { __proto__: whatever, ... } is faster than Object.create

#

note that this is special syntax and the __proto__ there has no relation to Object.prototype.__proto__

#

but even that is slow compared to new whatever()

#

(but probably only because few people use it)

ivory patrol Jul 25, 2023, 3:00 PM

#

Ugh you know what I'd like? If basic stuff like this had already been figured out, but apparently that's too much to ask for on the web.... -.- /rant

undone frost Jul 25, 2023, 3:00 PM

#

yep. I'm still hoping that we get a "use a better language"; pragma in the future

#

that jettisons all of these bad ideas

#

for new bad ideas, probably 😮‍💨

#

but I can hope they're not as bad

ivory patrol Jul 25, 2023, 3:01 PM

#

I mean we just the DOM APIs hooked up to wasm and I'm never looking back.

undone frost Jul 25, 2023, 3:01 PM

#

ivory patrol I mean we just the DOM APIs hooked up to wasm and I'm never looking back.

except moving strings across the WASM boundary is terribly slow

ivory patrol Jul 25, 2023, 3:02 PM

#

Well yeah sth at Mozilla used to be working on this stuff until she left for some other company...

#

Very disappointing, don't know why there's no progress on that front.

#

Anyway, thanks for the ideas @undone frost

dusk storm Jul 25, 2023, 3:03 PM

#

All this work to fight against a pattern the language doesn't support 😅

ivory patrol Jul 25, 2023, 3:04 PM

#

JS supports this pattern just fine, question is why TS devs don't care about basic stuff being broken.

dusk storm Jul 25, 2023, 3:06 PM

#

Can't speak for others, for me personally static inheritance is not something required for OOP to function, and as said that's the case for plenty other OOP languages.

#

This is far from the only JS pattern that TS doesn't support.

ivory patrol Jul 25, 2023, 3:10 PM

#

Well I'm pretty this is as good as it's gonna get until issue #3841 is resolved so

#Static property access in abstract and subclasses results in errors