Why is still possible to cast all types of variable to "any" in TypeScript?

66 Views Asked by At

I am still adapting coding using typescript. I am a full stack developer, used with C#, an OOP language. I really don't like dynamic typed languages, and fortunately I still dont have to work with any yet.

I just realized how bad is "any" casting, specially for begginers and people not used with OOP. I mean, it's ok to a generic method to return an any value - at least I can handle with it -, such as retrieving data with axios, rxjs or from local storage, for example, because they're type can really vary.

But what is really annoying me that this is illegal:

class C1 {id: string}
class C2 {num: number}

const c1 = new C1()
const c2: C2 = c1;

But this for typescript is totally ok:

class C1 {/*...*/}
class C2 {/*...*/}

const c1 = new C1();
const c2: C2 = c1 as any;

The app I am currently developing has a bunch of these castings, and often when I refact anything, this causes a lot of trouble, creates bugs, etc.

This is totally nonsene, it's just like "Oh, an error? Let me cast "any". Works " and BOOM! The bomb was set

Can someone explain to me if is there any real utility for this possibility?

I actually agree with the OOP, that when we create a generic method, we must set a type, when we declare the function or method - I know, in C# there is the object type, but that is really rare and highly not recommended to use -, and TS has the exactaly same functionality:

// C# E.g.:
public T GenericMethod<T>() {
  //...
}

var c1 = GenericMethod<C1>();

// TS E.g.:
genericMethod<T>() {}
// or even
genericMethod = <T>() => ({} as T);

This standard is really helpful for getting data from DB Contexts, localStorage, axios, etc, and its easier to handle the possible exceptions

1

There are 1 best solutions below

2
Nicholas Tower On

I just realized how bad is "any" casting

I'm right there with you. I've gotten the nickname "The Any Police" due to the fact that i basically never let one pass through code review.

any exists for a specific purpose: To make adoption of typescript easier. Especially in the early days, it was quite common for a codebase to start in javascript and then get converted to typescript piece by piece. any is the type that plain javascript variables have, and typescript does not perform type checking on them, except in cases where it can infer the type. The intention is that codebases will start off with many any's, and overtime replace them with real types.

Once a codebase is entirely or primarily in typescript, any's hold it back. They disable typechecking (by design), so they will allow mistakes to slip by, such as the ones you mentioned. On rare occasion they can be useful for telling typescript "trust me, i know what i'm doing, so don't check me here", but they should be avoided. Unfortunately, it looks like the codebase you're inheriting doesn't have The Any Police to keep it in check.


PS, while doing as X is sometimes referred to as "type casting", it's better to call it and think of it as a "type assertion". You are asserting to typescript "trust me, this is the type". Nothing actually changes at runtime, so if the assertion was a mistake and it's not actually that type, typescript can't help you