Owen - Either I'm misinterpreting your answer or it is simply wrong. Typescript only does compile-time type-checking. All it knows about data coming from outside is what hypothetical type you have assigned to your input parameters; but no run-time type checking or data-validation is embedded into the compiled code that actually handles the data: it has been compiled to plain JavaScript with no type checking.
In the example given Typescript is no help at all: the application would simply crash. I've seen this happen recently in an application taking data from a PHP backend out of our control. The data didn't conform to the data type we expected and our application bombed because someone forgot to add the proper checks. This was in QA so no big deal; but could have been really problematic if it had slipped through the net.
I think it would be unfair to call this a flaw in Typescript; but it is really important that people understand this. Typescript is not a substitute for doing proper type-checking/validation on data that is outside your control.
If that was to me, you need to read it in context.
tsc doesn't generate type checking logic, it does static tranpilation analysis based on what you've told it about the types. If you tell it the Web API result returns a number, it'll roll with it and find no issues (assuming you treat it like a number). Since it transpiles down to JavaScript, the variable will still get assigned a string and you get the same sort of an issue down the road. That's why it's important to get your type definitions correct as well as potentially validate them at the boundaries with a typeof check.
Also bear in mind union types and nullability are supported in TypeScript and should be considered and used. The benefits once you understand them are great, however.
Owen - Either I'm misinterpreting your answer or it is simply wrong. Typescript only does compile-time type-checking. All it knows about data coming from outside is what hypothetical type you have assigned to your input parameters; but no run-time type checking or data-validation is embedded into the compiled code that actually handles the data: it has been compiled to plain JavaScript with no type checking.
In the example given Typescript is no help at all: the application would simply crash. I've seen this happen recently in an application taking data from a PHP backend out of our control. The data didn't conform to the data type we expected and our application bombed because someone forgot to add the proper checks. This was in QA so no big deal; but could have been really problematic if it had slipped through the net.
I think it would be unfair to call this a flaw in Typescript; but it is really important that people understand this. Typescript is not a substitute for doing proper type-checking/validation on data that is outside your control.
If that was to me, you need to read it in context.
tscdoesn't generate type checking logic, it does static tranpilation analysis based on what you've told it about the types. If you tell it the Web API result returns anumber, it'll roll with it and find no issues (assuming you treat it like anumber). Since it transpiles down to JavaScript, the variable will still get assigned astringand you get the same sort of an issue down the road. That's why it's important to get your type definitions correct as well as potentially validate them at the boundaries with atypeofcheck.Also bear in mind union types and nullability are supported in TypeScript and should be considered and used. The benefits once you understand them are great, however.
Matt - my response saying the answer given was incorrect was not directed at you. I've edited it to make that clearer ;)