Help me understand generic class interfaces

[dark aurora]

Is my understanding correct that the below class is a generic type that requires all fields coming from the inferred interface of SomeOtherClass?

export class MyClass<T extends SomeOtherClass> extends SomeOtherClass {...}

In other words, if SomeOtherClass implements an interface called OtherInterface, and this interface looks like this:

interface OtherInterface {
  someField: string;
}

Then MyClass has to have a static property that is of type string called someField, but in addition it can have any other type of property, because it is a generic T?

At least this is what I was trying to achieve with the above.

[unkempt ruin]

I think you're mixing up a bunch of different concepts

namely inheritance, generics, and static properties

[dark aurora]

Thanks @unkempt ruin, I think I can understand if you explain it to me.

[unkempt ruin]

Then MyClass has to have a static property that is of type string called someField
not static, but will have an instance property someField: string
but in addition it can have any other type of property, because it is a generic T?
it can have other properties, since it's extending a class
the generic is completely irrelevant tho

[dark aurora]

Hi, your understanding is partially correct.
When you define MyClass like this, it inherits all properties and methods of SomeOtherClass the generic T is a type that extends SomeOtherClass, but it doesnt automatically add new properties to MyClass

You can use T for creating new properties or methods inside MyClass that depend on the type T

[merry thistle]

Ascor8522#7606

Playground Link

Preview:```ts
class A {
// A has a field a of type string
a!: string
}

class B extends A {
// B is A (it has the a property) plus some other fields (b)
b!: string
}

interface I {
i: string
}

class C implements I {
// MUST have all properties and methods defined in
...```

You can choose specific lines to embed by selecting them before copying the link.

[dark aurora]

Ok, maybe I understand you now. So it can have other instance properties regardless since it extends the SomeOtherClass. But if I want those to be typesafe, writing <T extends Surreal> like I have done is correct as long as I pass the type when I use the new keyword?

yes you can pass the type like this when creating a new instance of the class: new MyClass<SomeOtherClassLike>()

[unkempt ruin]

But if I want those to be typesafe, writing <T extends Surreal> like I have done is correct as long as I pass the type when I use the new keyword?
yes
the type extends Surreal describes the "minimum shape" T must have
so the property of type T inside your class will have all the properties of the Surreal type

[dark aurora]

One last question, is TS inferring the type of the Surreal class?

that ^^, I like "minimum shape" 😄

[unkempt ruin]

is TS inferring the type of the Surreal class?
it can, if the type T is used somewhere in a prameter or return type of the function/constructor

[dark aurora]

Thanks Ascor, the "minimum" thing was my understanding and good that it works that way 🙂

you can use Classes just like types/interfaces in TS i think

[dark aurora]

Great to know!

so yes it should infer the type

Is there any good overview documentation that describes the basics of where in JavaScript we can write TypeScript. I see TypeScript written using <> and I see it using :.

For example, when I attempted to write new MyClass<MyType>() I did not know whether <> should be placed before or after the class name. Is there some rule that I should know?

[unkempt ruin]

he basics of where in JavaScript we can write TypeScript
huh?

[dark aurora]

Yeah, strange questions, I know 🙂

[unkempt ruin]

TypeScript IS JavaScript plus some added type system

[dark aurora]

check out https://www.typescriptlang.org/docs/handbook/2/generics.html

I think the <type> is almost always before the ()

: is the return type of type of the variable, so it comes after the () of the function or after the variable name

[unkempt ruin]

I see TypeScript written using <> and I see it using :
not sure what you mean by that
<> (also known as the "diamond operator" in other language) is used for generics in TypeScript
: can be used in a lot of different places

• JS/TS object litterals ({ foo: "bar" })
• TS types (function foo(param: Type): OtherType { [...] })
• JS/TS ternary opertor (condition ? true : false)
  note the teranry operator can also be used in TS for types (conditional types) (T extends Type ? TypeA : TypeB)

[dark aurora]

<> can also be the parameters of another type like Record<string, number>

Thank you @unkempt ruin and @dark aurora!

I guess there is no point in typesetting a static class, since you mentioned that classes are themselves considered to be a sort of type and their properties by themselves define its type?

I assume it only makes sense to typeset instances, since those are dynamic.

[unkempt ruin]

exactly, you can use a class like you would use an interface in other languages (I have Java in mind where this is a common thing to do, but also papplies to other languages)

so yeah, use the class as type for the concrete and "abstract" types

[dark aurora]

Thank you very much!

I would only use generics for "dynamic" things, just like the default TS types,

Promise<boolean> // promise knows that it has to resolve with a boolean
Record<string, number> // keys can only be string and all values must be numbers

so only generics are only useful when you allow some "customization" if you know what I mean

and let TS infer things itself whenever it can

Thank you, that is a good rule of thumb. And also we shouldn't define types for everything, only if it does not have a type and cannot infer.

[unkempt ruin]

we shouldn't define types for everything, only if it does not have a type and cannot infer.
that's debatable
basically comes down to personnal preferences

[dark aurora]

There is one complication, which is that if we rely on a type soehwere in our code and we remove that piece of code, TS may scream at us.

defining more types can also help the TS compiler to avoid some performance issues, but thats rare

[unkempt ruin]

exactly, I like using some kind of "constract first" approach
where I write the types for the parameters and the return type of the function
so that if the internal change, the changes don't leak outside of the function because everythign is inferred

[dark aurora]

Now that I know a bit more about TS, maybe my TS will break 😛

[dark aurora]

I was thinking the same. Do you usually write it 1) at the top of the file, 2) as part of an object/function scope 3) at the bottom of the file? I assume types are always global scope.

they can be global, but you can also use typeof someVar then it could be considered local

[unkempt ruin]

usually at the tope of the file if they are also needed elsewhere (exported)
maybe near the bottom if they are only used in that file and that file only (utility types)
and in some rare cases, if the type is only used within the function

[dark aurora]

I have never written an "abstract" type. Like MyType is a function that returns something. But I have seen some syntax that looks something along the lines of Type MyType = () => string

So far, I have applied my types on the objects themselves. In what part of the TS documentation can I learn the syntax for writing such "abstract" types as mentioned above?

[unkempt ruin]

definitely the "type manipulation" section

https://www.typescriptlang.org/docs/handbook/2/types-from-types.html

it's part of the slightly more "advanced" stuff of the language

[dark aurora]

Is typeof JS or TS? (apart from being new to TS, I am also new to JS).

EDIT: I found on the TS website that it is a special operator.

[dark aurora]

Thank you very much, great to have a reference to it. I need to learn how the docs on TypeScript website is structured so I can find what I need.

[unkempt ruin]

it's a bit of a mess tbh
so I suggest reading the whole thing at least 1 time
doesn't have to be in 1 sitting, but it really helps

[dark aurora]

typeof is TS or JS xD

// this is JS
if (typeof x === 'string') {}

const x = 22;
// this is TS (inside the type)
const y: typeof x = 5;

so y gets the type of x

[dark aurora]

That makes it more confusing 🙂

I was learning about JS classes yesterday, and for a long time I thought that private was part of JS, but it is actually a TS thing.

[unkempt ruin]

yeah, while knowing JS isn't technically required, it's strongly recommended

[dark aurora]

its very useful when you dont want to repeat yourself too much:

class X {
 profile = {name: string; age: number};
 ...

 addNewProfile(p: typeof this.profile) {...}
}

Ok, nice, so here you are defining a type that is only visible inside the class context

But shouldn't it be Type profile?

its good to learn what is TS and what is JS, this will help you identify it.
I mean TS = "only the types stuff"

[dark aurora]

That part I understand

[dark aurora]

yes, typo, typeof edited it

Oh now I see, it is the JS operator you are using

In combination with the TS :

so in that class, only the : typeof this.profile is TS types
is pure JS you also cannot define the profile like that, but might be soon

"The typeof operator returns a string indicating the type of the operand's value."

right, so like Ascor said,
TS is just JS... but with some extras

[dark aurora]

Thank you, now I got it.

That makes sense why MS decided to call it typeof in that case.

[dark aurora]

happy to help 🙂

Thank you both very much, TS is pretty tricky and fun 🙂

[dark aurora]

!resolved